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ABSTRACT 


Complex  defense  acquisition  programs,  such  as  the  Global  Positioning 
System  program,  have  many  requirements  engineering  challenges  to  overcome 
in  order  to  deliver  capabilities  to  customers  and  satisfy  other  stakeholders.  To 
meet  these  challenges  and  stay  within  cost  and  schedule  constraints,  engineers 
and  managers  need  system  requirements  information  organized  in  a  clear, 
complete,  and  efficient  manner  to  support  decision  making.  An  effective 
methodology  tailored  to  the  needs  of  the  program  decision  makers  will  ensure 
that  important  information  is  correct,  organized,  and  readily  accessible.  The  GPS 
program  is  implementing  a  methodology  that  includes  standardized  processes 
across  its  segments.  However,  the  GPS  program  refrained  from  implementing  a 
better  requirements  engineering  approach  and  using  its  current  requirements 
engineering  tool  to  take  advantage  of  this  approach. 
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I.  INTRODUCTION 


A.  BACKGROUND 

With  the  Global  Positioning  System  (GPS)  program  as  an  example,  this 
research  pursued  the  discovery  of  efficient  and  thorough  methods  for  integrating 
system  requirements  across  generations  of  system  deliverables  that  incorporate 
new  technologies  and  capabilities.  Known  as  the  Navstar  GPS  Joint  Program 
Office  until  it  was  renamed  in  August  2006,  the  GPS  Wing  is  the  United  States 
Air  Force  (USAF)  system  program  office  responsible  for  planning  and  acquiring 
deliverables  that  provide  new  GPS-based  capabilities.  Current  practices  expose 
the  GPS  program  to  the  risk  that  technical  incompatibilities  will  result  across 
different  blocks  or  generations  of  subsystems  and  their  hardware  and  software 
interfaces.  The  reason  for  this  is  that  not  all  relevant  information  is  recognized 
and  controlled  by  a  central  authority  through  a  single,  formal  methodology.  This 
research  identified  a  more  effective  methodology  for  tracking  the  impact  of  every 
change  or  proposed  change  made  to  the  GPS  technical  baseline.  The  GPS 
Wing  could  implement  this  approach  with  its  existing  requirements  engineering 
tool.  Telelogic  AB’s  DOORS  7.1  database,  and  provide  better  decision-making 
support  to  GPS  Wing  leaders  as  a  result. 

The  pursuit  and  recognition  of  valuable  and  timely  information  is  a  quest 
that  persists  for  decision  makers.  Having  ready  access  to  knowledge  of  decision 
impacts  across  system  segments  and  their  successive  deliverables  would  allow 
program  decision  makers  to  balance  various  and  often  competing  system 
program  objectives  confidently.  The  outcome  of  this  research  recommends  and 
demonstrates  a  requirements  engineering  methodology  that  helps  systems 
engineers  to  answer  the  research  questions  posed  below.  When  implemented 
fully,  the  GPS  program’s  systems  engineers  should  be  able  to  take  advantage  of 
this  methodology  to  perform  quick  and  comprehensive  technical  analyses  that 
support  recommendations  to  the  GPS  Wing  Commander.  The  GPS  Wing 
Commander  serves  as  the  GPS  System  Program  Director  (SPD). 
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B.  PURPOSE 

The  greater  purpose  of  this  research  effort  was  to  offer  requirements 
engineering  improvements  within  the  GPS  program  that  systems  engineers 
outside  of  the  GPS  Wing  could  apply  for  the  benefit  of  their  own  acquisition 
programs.  Programs  that  could  benefit  include  other  space  programs  that  are 
held  in  the  Space  and  Missile  Systems  Center  (SMC)  portfolio  of  acquisition 
programs  at  Los  Angeles  Air  Force  Base.  (SMC  funded  the  author’s  participation 
in  the  degree  program  for  which  this  thesis  satisfies  a  graduation  requirement.) 
Ultimately,  this  research  effort  establishes  an  appropriate  requirements 
engineering  methodology  for  the  GPS  program  and  contributes  to  the  set  of  best 
practices  that  help  systems  engineers  and  program  managers  for  any  complex 
system  improve  the  level  of  cost,  schedule,  and  technical  success  of  their 
respective  programs. 

C.  RESEARCH  QUESTIONS 

The  following  research  questions  describe  the  extent  of  discussions  that 
involved  this  author  and  other  members  of  the  GPS  Wing  at  the  onset  of  this 
research  effort.  This  paper  addresses  all  of  these  questions. 

1.  If  the  GPS  program  makes  a  decision  to  change  a  number  in  one 
place  in  the  requirements  or  specifications,  how  does  the  program  track 
and  assess  the  impacts  or  ripples  across  system  segments  and 
capabilities?  This  question  includes  the  following  facets: 

a.  Requirements  traceability 

b.  Requirements  effectivities 

c.  Offline  tools 

d.  Varying  classification  levels 

e.  Contracts 
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2.  What  does  the  current  requirements  engineering  technology, 
DOORS,  do  well  for  the  GPS  program  and  what  does  it  fail  to  do  well  or  at 
all  for  the  program? 

3.  In  what  ways  are  requirements  documented? 

4.  What  should  the  GPS  program  do  about  requirements  that  it 
anticipates  and  will  affect  other  subsystem  or  segment  deliverables,  but  do 
not  exist  yet? 

For  example,  there  will  be  a  requirement  to  monitor  the  newest  GPS 
signals.  One  satellite  that  can  broadcast  the  M-Code  signal  is  in  orbit 
already,  but  it  will  be  years  before  the  GPS  has  a  monitoring  capability 
to  support  future  GPS  users  of  this  type  of  signal. 

5.  What  are  the  appropriate  roles  and  relationships  of  the  Capabilities 
Development  Document  (ODD),  specifications,  and  Interface  Control 
Documents  (ICDs)? 

a.  For  example,  is  the  word  shall  in  ICDs  appropriate  or,  rather 
than  provide  direction,  should  ICDs  simply  describe  interfaces? 

b.  How  are  ICDs  handled  in  contracts  when  compared  to  other 
documents? 

6.  How  should  the  program  state  requirements  when  perspectives 
differ  across  subsystems  and  segments? 

7.  What  are  the  characteristics  of  a  “good”  requirement? 

8.  How  can  the  program  capture  the  rationale  behind  a  requirement? 
It  can  be  important  to  know  whether  a  requirement  exists  because  it  is 
achievable  or  because  of  analysis. 

9.  How  do  a  vendor  and  client  verify  that  a  particular  requirement  has 
been  satisfied? 

10.  Who  are  the  GPS  program’s  customers  and  other  stakeholders? 
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Figure  1  below  shows  one  way  to  organize  these  questions  to  see  how 
they  relate  to  each  other  in  the  context  of  system  requirements  engineering. 
There  are  four  categories  into  which  these  research  questions  fit,  and  these  are 
summarized  as  the  following  general  questions: 

•  Where  do  requirements  come  from? 

•  How  do  we  state  requirements  effectively? 

•  How  should  we  document  requirements? 

•  How  should  a  program  handle  requirements  changes? 


Where  do  reqts  come  from? 

Who  are  the  GPS 
program's  customers  and 
other  stakeholders? 

What  processes  ‘ 
between  sources 

define  interaction 
&  documentation? 

What  are  the  appropriate 
roles  &  relationships 
among  the  CDD,  system 
specs,  ICDs,  &  ISs? 

How  should  the  program  state 
reqts  effectively? _ 


What  are  the 
characteristics  of  a 
good  requirement? 


How  should  one  state 
reqts  to  accommodate 
perspectives  across 
subsystems  &  segments? 


How  can  the  program 
capture  the  rationale 
behind  a  requirement? 


How  do  a  vendor  and 
client  verify  that  a 
requirement  has  been 
satisfied? 


How  should  a  program  document 
requirements? 


How  does  the  GPS 
program  document 
requirements? 


What  does  DOORS  do 
well  for  the  GPS  program 
and  where  is  there  room 
for  improvement? 


How  should  a  program  handle 
reqts  changes? 

What  is  the  best  way  to 
handle  anticipated  reqts 
that  will  affect  other 
subsystems  &  segments? 


How  does  program  track 
&  assess  impacts  of 
reqts  changes  across 
segments  &  capabilities? 


Figure  1.  Relationship  of  Research  Questions  to  Requirements  Issues 
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D.  BENEFITS  OF  STUDY 

1.  Disciplined  and  Comprehensive  Requirements  Engineering 
Methodology 

A  methodology  can  assist  with  analyzing  the  impacts  of  the  factors  and 
influences  that  contribute  to  the  requirements  engineering  challenge.  A 
methodology  consists  of  three  main  components:  techniques,  models,  and  tools. 
Satzinger,  Jackson,  and  Burd  help  to  define  this  whole  and  its  components, 
which  are  paraphrased  as  follows: 

a.  Methodology  =  guidelines  for  completing  activities  in  a 
system  development  life  cycle  that  include  models,  tools, 
and  techniques 

b.  Model  =  a  representation  or  abstraction  of  something  real 

c.  Tool  =  something  that  helps  with  the  creation  of  models  or 
some  other  means  to  support  a  project 

d.  Technique  =  guidelines  such  as  step-by-step  instructions  or 
general  advice  for  completing  an  activity/task 

(After  Satzinger,  Jackson,  &  Burd,  2004) 


2.  Improved  Decision  Support  Resources  for  Program  Managers 
and  Systems  Engineers 

The  GPS  program  faces  many  complex  programmatic,  technical,  and 
political  challenges.  Effective  documentation,  analysis,  management,  and 
reporting  tools  for  system  requirements  help  program  managers  and  systems 
engineers  understand  the  impacts  of  decision  alternatives  and  ensure  that  they 
make  informed  decisions.  As  this  research  revealed,  the  GPS  Wing  uses  the 
DOORS  tool  without  taking  advantage  of  its  most  powerful  features.  Used  with  a 
more  effective  requirements-centric  model,  the  DOORS  tool  can  help  decision 
makers  improve  the  speed  and  quality  of  these  decisions  that  affect  the  evolution 
of  the  GPS. 
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E.  SCOPE  AND  METHODOLOGY 

1.  Thesis  Scope 

The  thesis  focuses  on  improving  the  models,  tools,  and  techniques  that 
support  GPS  requirements  engineering  from  the  elicitation  of  well-defined 
requirements  from  customers  through  the  integration  and  test  of  deliverables. 
The  requirements  engineering  recommended  improvements  can  ensure  that 
deliverables  as  designed  and  produced  will  satisfy  well-defined  requirements. 
This  thesis  addresses  current  shortfalls  and  concerns  identified  above  in  the 
research  questions.  In  particular,  the  research  findings  include  a  better  method 
for  ensuring  that  potential  impacts  of  new  or  modified  requirements  are  easy  to 
trace  quickly.  These  improvements  would  benefit  affected  stakeholders  who 
could  then  analyze  the  impacts  and  help  program  leaders  make  balanced 
decisions. 

2.  Approach/Methodology 

This  section  summarizes  the  activities  that  contributed  to  the  research 
results  and  conclusions  for  this  paper: 

a.  A  literature  review  of  requirements  engineering  best 

practices  and  GPS  requirements 

b.  Interviews  of  GPS  program  key  personnel  to  uncover 

shortcomings  in  integrating  requirements  effectively 

c.  Identification  of  current  GPS  requirements  engineering 
issues 

d.  Establishment  of  a  DOORS  account  and  receiving  DOORS 
training 

e.  A  review  of  how  requirements  from  various  relevant 

documents  are  currently  handled  in  DOORS  or  by  other  means 

•  system  specifications  and  derived  documents 
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•  Interface  Control  Documents  (ICDs)  and  Interface  Specifications 
(ISs) 

•  the  Capabilities  Development  Document  (CDD)  and  its  predecessor 
documents, 

•  requirements  documents  classified  at  various  levels 

f.  Identification  of  examples  of  how  processes  and  resources 
could  be  used  to  track  requirements  more  effectively  in  order  to  facilitate 
better  and  faster  requirements  engineering  decisions 


F.  ORGANIZATION  OF  THESIS 

Chapter  I  provides  an  introduction  to  the  GPS  Wing’s  requirements 
engineering  challenges.  In  Chapter  II,  this  paper  introduces  the  GPS  acquisition 
program  and  its  stakeholders.  Chapter  II  addresses  the  research  question 
regarding  where  requirements  come  from  and  also  describes  the  requirements 
management  process.  After  explaining  how  the  GPS  Wing  currently  documents 
requirements.  Chapters  III  and  IV  discuss  the  remaining  three  categories  of 
research  questions  from  Figure  1  above.  While  Chapter  III  focuses  on  an 
explanation  of  the  contents  within  the  literature  reviewed.  Chapter  IV  focuses  on 
the  application  of  the  knowledge  gained  from  both  the  literature  reviewed  and 
interviews  granted  by  GPS  Wing  personnel.  Chapter  V  provides  a  summary  of 
recommendations  and  proposes  areas  for  conducting  additional  research. 
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II.  THE  GLOBAL  POSITIONING  SYSTEM  (GPS)  ACQUISITION 
PROGRAM  AND  STAKEHOLDERS 


A.  THE  GLOBAL  POSITIONING  SYSTEM  (GPS) 

The  GPS  is  a  space-based  precision  position,  velocity,  and  timing  (PVT) 
system  conceived  as  a  U.S.  joint  civil-military  system  led  and  staffed  by  the 
United  States  Air  Force  with  participation  by  a  variety  of  other  U.S.  government 
agencies  and  foreign  military  representatives.  Other  terms  that  describe  GPS 
appropriately  are  Global  Navigation  Satellite  System  (GNSS)  and  Radio 
Navigation  Satellite  Service  (RNSS),  because  the  coverage  provided  by  the  GPS 
is  global  and  it  transmits  radio  frequency  signals  on  L-band  carrier  frequencies 
(from  1  GHz  to  2  GHz  according  to  IEEE  standards)  to  the  GPS  users.  GPS’s  L1 
and  L2  center  frequencies  are  1.57542  GHz  and  1.22760  GHz,  respectively. 
Figure  2  below  depicts  the  segment  components  of  the  GPS  and  may  serve  as  a 
helpful  visual  reference  for  the  more  detailed  explanation  that  follows. 
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Master  Control 
Station  (MCS) 


Monitoring 

Stations 


Figure  2.  General  depiction  of  the  Global  Positioning  System  segments  (After 

Kaplan,  2006) 

The  space,  ground  (or  control),  and  user  segments  represent  the  critical 

components  of  the  GPS  architecture.  From  the  master  control  station  (MCS)  or 

its  alternate  facility,  satellite  operator  personnel  command  and  control  the 

constellation  of  satellites  that  broadcast  signals  to  monitoring  stations  (to  create  a 

feedback  loop)  and  to  GPS  users.  Users  fall  into  two  general  categories:  civil  or 

military.  Civil  users  benefit  from  the  Standard  Positioning  Service  (SPS)  enabled 

by  the  coarse/acguisition  (C/A)  code  signals  broadcast  by  GPS  satellites  at  the 

L1  freguency.  Military  users  also  have  access  to  the  encrypted  Precise 

Positioning  Service  (PPS)  that  is  based  on  the  encrypted  signal  known  as  P(Y) 
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code,  and  this  signal  is  broadcast  at  the  L1  and  L2  frequencies.  If  the  SPS  is  not 
augmented  by  a  regional  ground-based  or  space-based  differential  GPS  system, 
the  PPS  will  provide  more  accurate  results  than  the  SPS.  The  National  Security 
Agency  (NSA)  supports  the  cryptography  needs  of  the  GPS  program. 

GPS  receivers  on  or  above  the  surfaces  of  the  earth  receive  signals  that 
are  broadcast  from  multiple  GPS  satellites  to  derive  accurate  ranging  information 
with  respect  to  each  satellite  and  calculate  unique  PVT  information  for  each  user 
in  real  time.  These  signals  are  a  combination  of  carrier  frequency  at  which  the 
GPS  receivers  receive  the  signals,  a  navigation  message,  and  a  ranging  code.  A 
GPS  satellite’s  unique  ranging  code  enables  receivers — with  their  satellite 
constellation  almanacs — to  distinguish  among  the  satellites  in  order  to  determine 
which  satellites  are  “in  view.”  The  use  of  these  unique  codes  is  necessary, 
because  unlike  radio  stations  that  each  use  different  frequencies  to  broadcast 
their  content,  the  GPS  signals  from  each  satellite  use  the  same  carrier 
frequencies  for  the  same  purposes.  The  information  regarding  ranges  to 
particular  in-view  satellites  allows  receivers  to  calculate  their  PVT  information. 
More  satellite  signals  available  to  a  receiver  typically  result  in  better  calculated 
solutions,  but  the  relative  positions  of  the  satellites  (the  geometry)  influence  the 
accuracy  of  the  calculations  also.  A  minimum  of  four  uncorrupted  or  “healthy” 
satellite  signals  are  necessary  for  accurate  position  information.  The  reason  that 
four  satellites  are  needed  instead  of  only  three  is  that  the  ranging  equations  that 
describe  the  distance  each  signal  travels  from  each  satellite  to  a  receiver  include 
the  3-dimensional  coordinates  for  the  in-view  satellites,  the  coordinates  for  the 
receiver,  and  the  receiver’s  clock  bias  with  respect  to  the  satellites  clocks.  In 
general  algebraic  terms,  the  receiver  would  need  four  equations  (one  for  each  of 
four  ranging  signals)  in  order  to  solve  for  the  four  unknowns:  the  user’s  x,  y,  and 
z  coordinates  and  receiver  clock  bias.  Not  taking  into  account  the  clock  bias  in  a 
receiver  can  result  in  position  errors  of  several  hundred  meters  even  with  the 
most  advantageous  relative  positions  of  only  three  satellites  to  each  other  and 
the  user.  Knowing  deviations  from  expected  satellite  ephemerides  also  improves 
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the  accuracy  of  receiver-calculated  positions.  Ample  technical  sources  provide 
more  detail  about  general  GPS  receiver  technology.  As  of  2006  and  in 
unobstructed  settings,  receivers  can  typically  track  eight  or  more  GPS  satellites 
than  are  needed  to  provide  accurate  results  to  users  (Kaplan  &  Hegarty,  2006). 

Satellite  operators  who  work  at  the  Master  Control  Station  command  and 
control  the  satellites  of  the  GPS  constellation.  The  operators  ensure  that  the 
control  segment  performs  the  following  functions  defined  by  Misra  and  Enge: 

•  to  monitor  satellite  orbits 

•  to  monitor  and  maintain  satellite  health 

•  to  maintain  GPS  Time 

•  to  predict  satellite  ephemerides  and  clock  parameters 

•  to  update  satellite  navigation  messages 

•  to  command  small  maneuvers  of  satellites  to  maintain  orbit,  and 

relocations  to  compensate  for  failures,  as  needed 

(Misra  &  Enge,  2001) 

Some  of  the  functions  above  relate  to  the  new  navigation  messages  the 
operators  create  and  transmit  to  satellites  in  order  maintain  the  GPS 
performance.  Operators  predict  ephemerides  and  clock  parameters  using  data 
obtained  from  the  monitoring  stations  dispersed  around  the  globe,  and  provide 
these  predictions  in  the  navigation  message  that  is  uploaded  at  least  one  each 
day  to  each  satellite  via  ground  antennas.  Deviations  from  expected  satellite 
orbits  (or  ephemerides)  occur  as  a  result  of  astronautical  phenomena  such  as 
solar  pressure  and  because  the  operators’  gravity  model  is  not  perfect.  The 
result  of  clock  predictions  is  a  definition  of  GPS  Time  and  an  effective 
synchronization  of  GPS  satellite  atomic  clocks.  These  clocks  are  subject  to  very 
small  errors  that  are  still  large  enough  to  cause  significant  errors  (several 
hundreds  of  meters  in  position)  in  receiver  position  calculations.  GPS  clocks  use 

either  cesium  or  rubidium  frequency  standards  that  are  among  the  most  stable 
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and  precise  clocks  in  existence.  With  the  clock  and  ephemerides  error 
information  broadcast  via  the  navigation  message  to  and  then  from  satellites, 
users’  receivers  can  reduce  the  amount  of  error  in  their  calculated  PVT  solutions. 
As  the  amount  of  time  increases  from  the  last  update  to  the  navigation  message, 
the  magnitude  of  PVT  errors  increases  with  the  increasingly  older  satellite  clock 
and  ephemerides  parameters. 

The  orbits  for  the  GPS  constellation  include  24  primary  orbital  slots — one 
for  each  satellite  and  four  in  each  of  six  orbital  planes  to  provide  nearly  even 
coverage  around  the  globe.  For  several  years,  there  have  been  surplus  satellites 
distributed  (not  necessarily  evenly)  across  the  planes  of  the  constellation  and 
contributing  to  the  quality  of  the  PVT  information  provided  to  users.  Older 
satellites  that  are  closer  to  failure  tend  to  be  placed  near  other  such  satellites 
either  in  the  same  plane  or  in  adjacent  planes  to  ensure  robust  coverage  around 
the  globe.  Constellation  management  decisions  like  these  involve  analysis  of  the 
most  likely  failure  scenarios  and  their  impacts.  An  AFSPC-wide  community 
meets  quarterly  to  make  decisions  that  sustain  the  GPS  constellation  and 
minimize  the  service  degradation  in  terms  of  duration  and  geographic  footprint  on 
any  given  day.  This  body  takes  into  account  the  health  risks  forecasted  for  each 
satellite  and  each  plane  of  satellites.  Because  each  operational  satellite  makes 
an  impact  on  system  performance,  decisions  that  contribute  to  this  robustness 
often  involve  combining  decisions  to  choose  orbital  destinations  for  new  satellites 
and  to  reposition  satellites  currently  in  the  constellation.  Ultimately,  this  body 
shares  the  GPS  stakeholders’  number  one  priority  to  sustain  the  GPS  service  at 
a  high  level  of  quality. 

B.  THE  GLOBAL  POSITIONING  SYSTEM  (GPS)  WING 

1.  Organization 

The  GPS  Wing  is  a  program  office  responsible  for  the  acquisition  and 
evolution  of  the  GPS.  Several  program  office  Divisions,  Groups,  and  support 
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contractors  support  the  Wing  Commander  in  his  role  as  System  Program  Director 
(SPD).  These  organizations  fall  into  five  general  categories  shown  in  Figure  3: 


PRODUCT  DEVELOPMENT 

GROUPS  &  PRODUCT 

SUPPORT  DIVISIONS 

-Space  Segment  Group 
-Control  Segment  (CS)  Group 
-CS  Support  Division 
-User  Segment  Group 
-User  Equip.  Support  Division 

CORPORATE  SUPPORT 

-Aerospace  Corporation 
-MITRE  Corporation 
-System  Engineering  & 
Technical  Assistance 
(SETA)  support  contractors 
-Admin  &  computer  tech 
support  contracts 

FUNCTIONAL  SUPPORT 

DIVISIONS 

-Systems  Engineering 

-Contracting 

-Logistics 

-Management  Operations 
-Program  Control 

OTHER  PAYLOAD  DIVISION 

-Nuclear  Detonation 
(NUDET)  Detection 

System  (NDS) 

STAKEHOLDER  DIVISIONS 

-Army 
-Civil  Users 
-National  Geospatial 
Intelligence  Agency  (NGA) 
-Navy 

Figure  3.  GPS  Wing’s  Division,  Group,  and  Corporate  support  for  the  SPD 

2.  Roles  and  Responsibilities 

a.  Product  Development  and  Product  Support 

The  GPS  Wing  has  a  product  development  Group  for  each  of  the 
three  GPS  segments:  ground  (or  control),  space,  and  user.  They  each  manage 
their  own  development  contracts,  and  work  with  the  System  Engineering  and 
Logistics  Divisions  to  ensure  compatibility  of  requirements,  effective  integration. 
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test,  delivery,  and  user  acceptance  of  new  system  components.  The  Contracting 
and  Program  Control  Divisions  also  support  the  changing  needs  of  these 
acquisition  efforts. 

The  Space  Segment  Group  is  responsible  for  the  acquisition  of  the 
space  vehicles.  Current  acquisition  efforts  include  the  Block  IIR-M  satellites, 
some  of  which  remain  to  be  launched,  the  Block  IIP  satellites  being 
manufactured,  and  the  Block  III  variants  for  which  the  GPS  Wing  has  not  chosen 
a  vendor. 

The  Control  Segment  Group  is  responsible  for  the  upgrade  of  the 
current  and  acquisition  of  the  new  ground  infrastructure  necessary  to  command 
and  control  the  space  vehicles.  This  infrastructure  includes  master  control 
stations  (primary  and  backup),  ground  antennas,  monitoring  stations,  other 
communications  equipment  (switches,  routers,  and  transmission  lines)  to  connect 
these  modules,  and  the  software  necessary  to  integrate  and  operate  this 
equipment.  Software  acquisition  is  a  challenging  part  of  the  Control  Segment 
modernization  that  has  resulted  in  cost  and  schedule  overruns.  The  Control 
Segment  also  uses  the  Air  Force  Satellite  Control  Network  (AFSCN)  Remote 
Tracking  Stations  (ARTS)  to  support  testing  and  satellite  orbital  movement 
operations,  and  National  Geospatial  Intelligence  Agency  (NGA)  monitoring 
stations  to  augment  the  GPS  monitoring  stations  around  the  world. 

The  Control  Segment  Product  Support  organization  in  Colorado 
Springs,  CO  provides  product  maintenance  and  upgrade  services  requested  by 
the  operators.  Upgrades  can  include  changes  to  the  user  interface  or  additional 
functions. 

The  User  Segment  is  responsible  for  the  acquisition  of  GPS  PPS 
receivers  used  by  U.S.  and  allied  foreign  military  services.  Products  acquired  by 
this  segment  include  the  Precision  Lightweight  GPS  Receiver  (PLGR)  handset 
and  the  Combat  Survivor  Evader  Locator  (CSEL)  system.  Current  acquisition 
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programs  include  more  advanced  hand-held  and  platform-mountable  receivers 
for  navigation  and  precision  targeting. 

The  User  Equipment  Support  Division  at  Robbins  Air  Force  Base, 
GA  provides  support  for  the  GPS  military  receiver  users.  This  support  includes 
user  training  as  well  as  equipment  maintenance,  troubleshooting,  and  upgrades. 

b.  Corporate  Support 

Like  the  other  program  offices  at  the  SMC,  the  GPS  Wing  relies  on 
the  invaluable  technical  support  provided  by  corporate  partners.  These  include 
the  The  Aerospace  Corporation,  The  MITRE  Corporation,  and  System 
Engineering  and  Technical  Assistance  (SETA)  contractors. 

The  Aerospace  Corporation  and  The  MITRE  Corporation  are  both 
Federally-Funded  Research  and  Development  Corporations  (FFRDCs)  that 
receive  funding  from  Congress  and  operate  as  non-profit  corporations.  This 
allows  employees  of  both  corporations  to  have  the  privilege  of  access  to  vendors’ 
proprietary  information  when  such  access  is  necessary  to  support  official 
government  business.  This  information  is  usually  technical  in  nature  since  most 
employees  of  these  FFRDCs  are  engineers  or  their  managers.  This  special 
status  precludes  these  FFRDCs  from  competing  against  vendors  who  do  operate 
for  profit.  Aerospace  has  its  headquarters  adjacent  to  Los  Angeles  Air  Force 
Base  in  El  Segundo,  CA  and  has  the  larger  presence  of  the  two  firms.  MITRE 
has  its  headquarters  in  Bedford,  MA  and  an  office  in  El  Segundo,  CA. 

Apart  from  the  FFRDCs,  for-profit  contractors  compete  for  SETA 
contracts  to  support  the  GPS  Wing’s  technical  needs.  Employees  of  these  firms 
support  the  GPS  Wing  in  a  manner  similar  to  that  of  the  FFRDCs.  At  the  time  of 
this  research  effort,  these  firms  included  ARINC  Engineering  Services,  LLC  of  El 
Segundo  as  prime  contractor;  Science  Applications  International  Corporation 
(SAIC);  Tecolote  Research,  Inc.;  Overlook  Systems  Technologies,  Inc.;  and 
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Teledyne  Brown  Engineering,  Inc.  Different  firms  support  administrative  and 
information  technology  needs  through  other  contracts. 

c.  Functional  Support  Divisions 

The  functional  support  divisions  along  with  their  assigned  corporate 
supporter  team  members  serve  to  accommodate  and  balance  the  needs  of  the 
product  development  groups  and  product  support  organizations,  represented 
stakeholders,  and  the  NDS  program. 

The  GPS  Wing’s  Systems  Engineering  Division  guides  the  analysis 
and  design  of  the  GPS  system  architecture  and  capabilities.  This  work  includes 
defining  and  coordinating  requirements  documents  that  include  the  Capability 
Development  Documents  (CDDs),  system  and  segment  specifications,  interface 
control  documents  (ICDs),  Interface  Specifications  (ISs),  and  other  technical 
guidance  necessary  to  meet  operator  and  user  needs.  Vendors  use  this 
guidance  to  design  their  subsystems  and  validate  the  performance  of  these 
designs.  All  stakeholders  voice  their  input  to  ensure  that  program  decisions 
accommodate  their  needs.  The  Chief  Engineer  and  ultimately  the  Wing 
Commander  balance  these  needs  based  on  the  guidance  and  direction  from  the 
DoD,  regulatory  bodies,  and  the  needs  of  the  GPS  stakeholders.  Section  D1 
explains  the  division  of  responsibilities  within  the  Systems  Engineering  Division. 

The  Chief  Engineer,  Group  Commanders  and  Wing  Commander 
cannot  make  informed  decisions  without  consulting  with  the  GPS  Wing’s 
Program  Control  Division.  This  division  has  financial  and  cost  analyses  branches 
to  help  ensure  that  the  program  only  takes  actions  that  the  Wing’s  budget  will 
allow.  While  the  Systems  Engineering  Division  focuses  on  technical  baselines 
and  the  Program  Control  Division  focuses  more  on  cost  and  schedule  baselines, 
both  divisions  must  work  together  with  the  product  development  groups  to 
balance  cost,  schedule,  and  technical  needs  of  the  GPS  Wing’s  acquisition 
programs.  The  Program  Control  Division  also  serves  as  the  focal  point  for 
external  (DoD)  requests  for  analysis. 
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By  negotiating  contracts  with  vendors,  the  GPS  Wing’s  Contracts 
Division  works  with  the  product  development  groups  to  ensure  that  these  firms 
will  design  and  build  GPS  subsystems  in  accordance  with  the  compliance 
documentation  included  on  the  respective  contracts.  The  Contracts  Division 
manages  several  development  contracts  and  oversees  the  bidding  for  others  like 
the  separate  Space  and  Control  Segments’  Block  III  contracts.  Control  over 
these  contracts  is  important  for  ensuring  that  the  multiple  prime  contractors 
deliver  GPS  subsystems  that  will  work  properly  with  the  other  vendors’ 
deliverables. 

The  GPS  Wing’s  Logistics  Division  works  with  AFSPC  to  meet  the 
integrated  logistics  support  (ILS)  needs  of  the  GPS  program.  Capt  M.  Ewer  of 
the  Logistics  Division  (personal  communication,  July  10,  2006)  describes  the 
division  of  responsibilities  as  they  are  summarized  in  Table  1  below: 


GPS  Wing-Level  Lead 

AFSPC-Level  Lead 

•  Maintenance  planning 

•  Support  and  Test  Equipment/ 

•  Supply  support 

Equipment  support 

•  Training  &  training  support 

•  Manpower  and  personnel 

•  Technical  data 

•  Computer  Resources  support 

•  Packaging,  Handling,  Storage, 

•  Facilities 

and  Transportation  (PHS&T) 

•  Design  interface 

Table  1 .  ILS  elements  allocated  among  GPS  Wing  and  AFSPC  levels. 


The  GPS  Wing’s  Management  Operations  Division  provides  office 
support  functions  to  meet  the  personnel  and  office  needs  for  all  GPS  Wing 
employees. 
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d.  Other  Payloads 

The  non-PVT  payload  that  the  GPS  program  supports  is  the 
Nuclear  Detonation  (NUDET)  Detection  System,  or  NDS.  The  DoD  decided  to 
add  this  payload  to  the  GPS  space  vehicles  in  order  to  leverage  the  continuous 
global  coverage  that  the  GPS  provides. 

e.  Stakeholders 

As  stakeholders  in  the  evolution  of  the  GPS,  other  government 
agencies  have  GPS  Wing  division-level  offices  to  represent  them  within  the  GPS 
program.  These  entities  include  the  other  US  military  services,  the  National 
Geospatial  Intelligence  Agency,  and  civil  users. 

The  Army’s  and  Navy’s  concerns  relate  directly  to  the  quality  of 
PVT  services  provided  to  their  respective  members  through  their  diverse  GPS 
receiver  equipment  sets.  There  are  many  adaptations  of  GPS  receivers  to  the 
needs  and  platforms  of  various  military  systems. 

Known  previously  as  the  National  Imagery  and  Mapping  Agency 
(NIMA),  the  National  Geospatial  Intelligence  Agency  (NGA)  provides  the 
information  necessary  to  relate  GPS  coordinates  to  the  geographic  features  of 
the  world.  Modeling  the  geographic  features  of  the  earth  is  part  of  a  discipline 
known  as  geodesy. 

The  civil  users  collectively  include  more  people  than  military  users, 
and  the  number  of  civil  applications  continues  to  expand.  While  these  users 
include  emergency  responders,  surveyors,  members  of  the  agriculture  industry, 
athletes,  and  many  others,  the  civil  agency  most  interested  in  the  evolution  of  the 
GPS  is  the  United  States  Department  of  Transportation  (DoT).  Within  the  DoT, 
the  Federal  Aviation  Administration  (FAA)  has  a  strong  interest  in  understanding 
and  influencing  policy  and  technical  decisions  for  the  GPS  in  order  to  support  the 
needs  of  civil  aviation  navigation  and  the  Wide-Area  Augmentation  System 
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(WAAS).  This  system  would  include  geosynchronous  satellites  to  work  with  the 
GPS  to  improve  GPS  accuracy  and  availability  to  satisfy  civil  aviation  navigation 
and  safety  requirements. 

The  satellite  launch  community  participates  in  constellation 
management  decisions  because  the  GPS  program  must  coordinate  the  timing  of 
its  launch  plans  with  the  launch  pad  schedule  controlled  by  the  launch 
community.  Launches  are  planned  several  years  in  advance,  and  are  subject  to 
changes  based  on  DoD  and  national  needs. 

3.  GPS  Program  Requirements  Challenges 

With  the  diverse  sources  of  change  to  the  system  that  include  the 
functional  support  divisions,  product  development  groups  and  product  support 
organizations,  and  other  stakeholders,  there  exists  the  risk  that  requirements 
generated  or  requirements  changes  made  for  one  part  of  the  program  will  have 
unintended  consequences  that  are  difficult  to  trace  or  accommodate.  The 
Systems  Engineering  Division  has  the  Herculean  task  of  managing  the 
complexity  of  the  GPS  program,  and  the  tools  used  and  frequent  turnover 
common  in  military  organizations  are  among  the  sources  of  confusion  and  risk  for 
which  a  stricter  approach  to  requirements  engineering  could  help  ensure  more 
effective  integration  of  the  system’s  components  across  system  segments. 
Every  requirements  integration/engineering  activity  should  strengthen  the 
program’s  ability  to  fulfill  its  mission  and  obligation  to  its  stakeholders.  These 
engineering  impacts  will  not  occur  without  contractual,  cost,  and/or  schedule 
implications. 

The  GPS  program  faces  engineering  challenges,  different  rates  of 
modernization  progress  across  the  three  segments,  and  a  tremendous  amount  of 
interest  and  use  beyond  the  Department  of  Defense.  With  respect  to  the  latest 
signals  and  associated  services.  Control  Segment  modernization  lags  behind 
Space  Segment  modernization,  and  both  lag  User  Segment  modernization.  For 

several  years,  users  have  had  GPS  receivers  that  are  capable  of  operating  within 
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the  improved  GPS  security  architecture  that  the  Control  Segment  will  not  be  able 
to  implement  for  at  least  two  more  years.  While  it  is  necessary  to  have  satellites 
in  orbit  that  can  support  the  newest  planned  capabilities  before  they  are 
implemented  by  the  Control  Segment,  the  Control  Segment  lags  far  enough  in 
development  that  it  cannot  support  requirements  engineering  work  needed  for 
the  Space  Segment  to  continue  its  own  software  development  efforts.  Also, 
influences  outside  of  the  Department  of  Defense  further  complicate  plans  to 
modernize  GPS.  These  constraints  include  domestic  and  international  laws  and 
regulations,  other  U.S.  government  agencies’  and  commercial  interests,  and 
international  agreements.  Program  managers  and  systems  engineers  must  be 
aware  of  these  constraints  as  they  contend  with  the  realities  of  the  acquisition 
program  baseline. 

C.  THE  GPS  ACQUISITION  PROGRAM  BASELINE  (APB) 

1.  Overall 

The  APB  describes  the  delivery  of  GPS  upgrades  and  capabilities: 
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Concept  I  I  Production  (S)  APB  Milestone  /\  Milestone  Objective  ^ 

Objective  _ 

Development  Platforms  /  Fielding  (Mar  05  I- 


^  Phase  1  -Initial  Test 

^  Phase  2  -  Enhanced  T&M 


Phases  -initial  PVT  {IOC) 
Phase 4  -Full  PVT (FOC) 


Figure  4.  April  05  GPS  Enterprise  Schedule  (D’Alessandro  &  Turner,  2006) 

Figure  4  summarizes  the  timing  of  GPS  modernization  activities.  The  top 
portion  of  the  figure  lists  the  new  capabilities  that  the  GPS  will  provide  over  time, 
while  the  bottom  three  sections  devote  themselves  to  summarizing  the 
modernization  of  the  three  GPS  segments.  It  is  through  the  modernization  of 
these  segments  that  the  new  features  will  become  available  to  GPS  users. 
Acronyms  in  Figure  4  are  defined  as  follows: 

•  Phase  2  -  Enhanced  Timing  and  (Navigation)  Messaging  (T&M)  refers  to 
an  improvement  in  both  of  these  named  capabilities 
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•  Initial  Operational  Test  and  Evaluation  (lOT&E)  is  a  phase  of 
system  testing  in  an  operational  environment 

•  The  Preliminary  Design  Review  (PDR)  is  the  forum  for  the 
appropriate  program  manager  to  determine  whether  or  not  “test  and 
analytical  evidence...  prove  that  all  performance  numbers  are  achievable 
and  no  significant  performance  risk  remains,  and  [whether  or  not]  the  end 
product  will  satisfy  the  customer”  (Forsberg,  Mooz,  &  Cotterman,  2000). 

•  The  Critical  Design  Review  (CDR)  is  the  forum  for  the  appropriate 
program  manager  to  determine  whether  or  not  “tests  and 
demonstrations...  prove  that  building  and  coding  to  the  proposed 
documentation  is  achievable  with  acceptable  risk  and,  [whether  or  not]  the 
end  product  will  satisfy  the  customer”  (Forsberg,  Mooz,  &  Cotterman, 
2000). 

•  Telemetry,  Tracking,  and  Control  (TT&C)  is  the  name  for  the 
information  provided  by  a  communications  bus. 

o  Telemetry  is  any  information  transmitted  from  a  remote 
location. 

o  Tracking  relates  to  information  used  to  determine  changes  in 
satellite  position. 

o  The  system  operators  control  the  satellites  with  messages 
provided  via  the  TT&C  communications  bus. 


2.  New  Capabilities 

New  capabilities  will  include  incremental  security  architecture 
advancements  known  as  (Block  I  IF)  SAASM  and  Block  III  Mil  Protect.  Newly- 
designed  signals  will  also  be  broadcast  at  frequencies  and  power  levels  that 
conform  to  U.S.  and  international  regulatory  filings.  Before  any  new  capability 
becomes  available,  each  segment  modernization  effort  must  achieve  its  own 
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milestones  in  order  to  support  delivery  of  the  capability.  The  difficulties  in 
achieving  these  milestones  are  revealed  below  in  the  respective  segment 
sections. 

The  second-generation  security  architecture  and  third-generation 
cryptography  are  known  collectively  as  SAASM.  This  acronym  is  misleading 
because  if  represents  more  than  the  Selective  Availability  Anti-Spoof  Modules  in 
GPS  receivers  that  have  been  available  to  the  P(Y)  code-based  Precise 
Positioning  Service  (PPS)  users  for  years.  When  supported  by  the  Block  IIP 
control  segment,  the  capabilities  linked  to  SAASM  will  improve  cryptographic  key 
distribution  to  PPS  receivers  (used  mostly  by  military  users)  and  reduce  their 
susceptibility  to  spoofed  GPS  signals  that  can  lead  to  significant  PVT  errors. 

Block  III  advancements  are  expected  to  include  another  civil  signal, 
controlled  signal  power  generation,  and  another  security  architecture 
improvement.  The  Block  III  security  architecture  that  will  replace  SAASM  is 
known  as  Military  Protect  and  will  work  with  the  M-Code-based  PPS.  The  term 
M-Code  is  the  accepted  shorthand  for  the  new  Military  Code  ranging  signal. 
Flex-power  will  be  a  capability  to  increase  the  GPS  signal  power  to  support 
military  needs  in  chosen  parts  of  the  world.  L1C  will  be  new  civil  signal 
broadcast  by  the  GPS  Block  III  satellites. 

L2C,  L5,  and  L1C  are  the  L-band  civil  signals  listed  in  the  order  they  will 
reach  Initial  Operating  Capability  (IOC)  and  Full  Operating  Capability  (FOC). 
These  signals  are  shown  in  the  GPS  Capabilities  section  of  the  GPS  Enterprise 
Schedule  in  Figure  4.  FOC  for  a  type  of  signal  requires  18  healthy  satellites  to 
broadcast  it.  Note  that  only  users  who  have  receivers  capable  of  processing 
these  new  signals  will  benefit  from  the  capabilities  offered.  The  M-Code  signal 
and  Flex-Power  feature  will  achieve  IOC  at  the  same  time  as  the  L2C  signal. 
The  reason  for  the  expected  simultaneous  realization  of  these  signals  and 
capabilities  is  that  these  all  depend  on  Block  IIR-M  satellites  and  the  satellite 
variants  that  will  follow.  Refer  to  Figure  4  to  see  this  type  of  connection  between 

the  GPS  segment  deliverables  and  capabilities. 

23 


3.  Space  Segment 

The  remaining  Block  II  generation  of  satellites  that  will  provide  new  signals 
includes  the  Lockheed  Martin  Block  IIR-M  and  the  Boeing  Block  IIF  satellites. 
The  IIR-M  vehicles  can  broadcast  the  L2C  Civil  Signal  and  the  M-Code  military 
signal.  The  Block  IIF  satellite  will  also  broadcast  the  L5  civil  signal,  which  is  of 
particular  interest  to  the  DoT  and  FAA  for  civil  aviation  use. 

The  GPS  Wing  has  not  chosen  the  vendor  that  will  design  and  build  the 
Block  III  generation  of  satellites,  but  these  satellites  will  add  the  L1C  civil  signal 
that  the  U.S.  government  expects  will  be  a  common  signal  among  GPS,  the 
European  Union’s  planned  Global  Navigation  Satellite  System  (GNSS)  known  as 
Galileo,  and  Japan’s  planned  Quazi-Zenith  Satellite  System  (QZSS)  to  augment 
the  GPS  over  Japan. 

Civil  users  currently  have  access  to  C/A  code  only,  as  other  signals  (L2C, 
L5,  and  L1C)  are  not  yet  available.  These  future  signals  will  allow  more  modern 
GPS  receivers  to  take  advantage  of  these  signals  in  order  to  improve  the  PVT 
solutions  they  calculate. 

4.  Control  Segment 

Like  the  Space  Segment,  the  Control  Segment  has  Block  II  and  Block  III 
upgrades  planned.  These  lag  behind  Space  Segment  modernization  and  are 
necessary  in  order  to  implement  the  capabilities  designed  and  built  into  the 
satellite  vehicles.  Currently,  the  Block  IIR-M  satellites  are  capable  of 
broadcasting  signals  that  the  Control  Segment  will  not  be  able  to  support  until 
Block  III.  The  first  Block  IIF  Control  Segment  delivery  will  replace  the  current 
system  and  provide  an  improved  system  architecture  and  system  operator 
interface.  The  second  delivery  will  add  the  SAASM  capabilities  described  in 
section  2  of  this  chapter.  After  reductions  in  scope  to  the  Block  IIF  Control 
Segment  contract,  this  series  of  deliverables  will  serve  largely  as  a  stop-gap 
between  the  current  Control  Segment  and  the  Block  III  Control  Segment.  In 
addition  to  enabling  new  SAASM  capabilities,  this  block  is  essential  for  providing 
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the  means  to  command  and  control  the  Block  IIF  satellites.  The  GPS  Wing 
decided  against  upgrading  the  current  system  to  support  Block  IIF  satellites. 

5.  User  Segment 

The  User  Segment  is  pursuing  a  variety  of  modernization  efforts  to  ensure 
that  military  users  have  the  ability  to  take  advantage  of  the  latest  capabilities 
available  to  them.  Beyond  making  the  necessary  technical  documentation 
available,  the  GPS  Wing  does  not  support  efforts  to  develop  or  produce  civil  user 
equipment.  User  Segment  programs  include  development  of  entire  receivers,  as 
well  as  new  hardware  that  the  User  Equipment  Support  Division  can  install  in 
existing  receiver  equipment.  New  capabilities  to  users  will  result  from  the 
following  list  of  active  programs: 

•  Advanced  Digital  Antenna  Panel  (ADAP)  for  aircraft 

•  Ground-Based  GPS  Receiver  Application  Module  (GB-GRAM)  for  a 

variety  of  U.S.  Army  platforms  and  munitions 

•  Defense  Advanced  GPS  Receiver  (DAGR)  handsets 

•  Miniature  Airborne  GPS  Receiver  (MAGR)  2000S 

•  Modernized  User  Equipment  (MUE) 

o  the  GPS  Wing  will  not  negotiate  a  contract  to  build  MUE 

o  the  GPS  Wing  supports  the  development  of  the  YMCA  card 

to  be  used  in  MUE  for  receiving  and  processing  the  current  military 
P-Code  (known  as  P(Y)-Code  when  encrypted),  the  future  military 
M-Code,  and  the  coarse  acquisition  (C/A)  code  signals. 

Current  military  GPS  users  have  receivers  that  are  capable  of  operating 
within  the  currently  unavailable  SAASM  architecture. 
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D.  CURRENT  REQUIREMENTS  ENGINEERING  METHODOLOGY 

1.  The  GPS  Wing  Systems  Engineering  Division 

The  Systems  Engineering  Division  serves  as  the  clearinghouse  for 
balancing  requirements  needs  across  GPS  Segments  and  stakeholders.  In 
particular,  the  Chief  Engineer  relies  on  the  Requirements  Branch,  Integration 
Branch,  Engineering  Projects  Branch,  and  Security  Engineering  Branch  to 
support  requirements  engineering  needs.  The  Test  Branch  supports  verification 
of  GPS  requirements. 

The  Integration  Branch  interacts  with  the  product  development  teams 
within  the  Space,  Control,  and  User  Groups  to  resolve  both  requirements  and 
design  conflicts.  The  latter  often  results  from  differences  in  interpretation  of  the 
former  by  two  or  more  development  teams  that  must  ensure  effective  interfaces 
between  their  deliverables.  Because  of  the  cross-segment  interaction,  the 
Integration  Branch  is  well-positioned  to  manage  most  of  the  Interface  Control 
Documents  (ICDs)  that  govern  the  many  GPS  subsystem  and  stakeholder 
interfaces.  However,  there  are  instances  where  vendors  that  are  responsible  for 
developing  a  subsystem  on  one  side  of  an  interface  also  have  control  over  the 
ICD.  These  vendors  are  called  Interface  Control  Contractors  (ICCs).  This  kind 
of  arrangement  causes  conflicts  because  the  vendor  developing  the  subsystem 
on  the  other  side  of  the  same  interface  is  left  at  a  disadvantage  when  the  ICC 
proposes  ICD  changes  and  implements  them  before  the  proposed  changes  are 
approved. 

With  the  input  of  the  GPS  program’s  customers  at  AFSPC  as  well  as  other 
stakeholders,  the  Requirements  Branch  creates  the  Capability  Development 
Document  (CDD),  the  System  Specifications,  the  Standard  Positioning  Service 
Performance  Standards  (SPS  PS)  and  the  Precise  Positioning  Service 
Performance  Standards  (PPS  PS).  Current  and  older  versions  of  these 
documents  apply  to  different  segment  development  efforts,  and  the  contracts  that 
are  relevant  to  those  efforts.  The  other  GPS  stakeholders  with  whom  the 
Requirements  Branch  interacts  include  the  Aviation  community’s  representatives 
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from  the  Federal  Aviation  Administration  (FAA),  the  U.S.  Department  of 
Transportation  (DoT),  and  the  International  Civil  Aviation  Organization  (ICAO). 
The  SPS  PS  document  includes  a  publicly  releasable  subset  of  information  that 
is  available  in  the  GPS  System  Specification,  top-level  system  interface  control 
document  (ICD),  and  some  lower-level  specifications  and  ICDs. 

The  Engineering  Projects  Branch  handles  international  and  domestic 
regulatory  issues  that  relate  to  the  approval  to  broadcast  signals  in  the  manner 
approved  by  the  appropriate  regulatory  bodies.  The  U.S.  government  files  for 
rights  to  broadcast  in  pre-determined  frequency  bands  and  at  negotiated  power 
levels  to  ensure  that  other  users  of  these  and  adjacent  frequency  bands  suffer  no 
harmful  interference  to  their  interests  as  a  result  of  GPS  operations.  The  U.S. 
Government  must  define  the  signals  that  the  GPS  broadcasts,  and  the 
Engineering  Projects  Branch  handles  the  signal  design  of  new  signals  to  ensure 
that  these  signals  meet  GPS  needs  for  supporting  users  and  satisfying  regulatory 
agreements. 

Once  part  of  the  Engineering  Projects  Branch,  the  recently-formed 
Security  Engineering  Branch  assumed  responsibility  for  all  GPS  security 
architecture  needs.  These  include  such  areas  of  concern  as  the  cryptographic 
protection  of  military  signals  for  use  by  only  authorized  users  as  well  as  other 
features  not  disclosed  by  the  program  for  security  reasons. 


2.  GPS  Requirements  Documents  and  Requirements  Sources 

Figure  5  summarizes  the  diversity  of  requirements  documentation  that 
guides  the  definition  and  evolution  of  the  GPS,  and  the  stakeholder  organizations 
that  contribute  to  that  documentation.  With  the  exception  of  the  Systems 
Engineering  Division,  the  categories  of  stakeholders  are  grouped  outside  of  the 
largest  box  in  the  figure  that  engulfs  the  names  of  the  requirements  documents. 

User  communities  such  as  the  membership  of  the  North  Atlantic  Treaty 
Organization  (NATO)  with  its  Standardization  Agreement  (STANAG),  the 
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classified  High-Accuracy  Navigation  Users  (HANU),  and  the  United  States  Coast 
Guard  (USCG)  are  among  the  users  outside  of  the  DoD  who  influence  the 
system.  The  civil  users  who  stand  out  include  the  domestic  and  international  civil 
aviation  organizations.  There  is  frequent  interaction  between  the  Department  of 
Transportation’s  (DoT’s)  Federal  Aviation  Administration  (FAA)  and  the 
international  body  of  which  it  is  a  member,  the  International  Civil  Aviation 
Organization  (ICAO).  This  interaction  influences  documents  such  as  the 
Standards  and  Recommended  Practices  (SARPs),  the  description  of  the  Future 
Radio  System  (FRS),  and  the  Standard  Positioning  Service  Performance 
Standards  (SPS  PS). 


System  Data 
Suppliers 


Non-DoD 
Signal  Design 
Sources, 
Constraints 


‘Agreements  with  foreign 
governments,  such  as 
Japan  (Quazi-Zenith 
Satellite  System)  and  the 
European  Union  (Galileo) 


Figure  5.  GPS  Requirements  Documents  and  Requirements  Sources  (After 

Alexander,  2006;  and  After  Chief  Engineer  Navstar  GPS  Joint  Program 

Office,  2006c) 
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Organizations  that  ensure  that  military  users  receive  suitable  receiver 
equipment  include  the  746‘*^  Test  Squadron  and  the  Space  and  Naval  Warfare 
Systems  Command  (SPAWAR).  Beyond  testing,  SPAWAR  is  responsible  for 
acquiring  and  integrating  GPS  receiver  equipment  on  Navy  and  Marine  Corp  sea 
and  air  platforms. 

The  customer  paying  for  the  GPS  is  the  U.S.  Air  Force  Space  Command 
(AFSPC),  which  receives  its  funding  from  headquarters  U.S.  Air  Force  (FIO 
USAF).  In  turn,  AFSPC’s  customer  is  the  50**^  Space  Wing  and  its  2'^'^  Space 
Operations  Squadron  known  as  2SOPS.  The  Interagency  Forum  for  Operational 
Requirements  (IFOR)  is  a  joint  civil-military  forum  chaired  by  the  AFSPC-level 
military  and  civil  requirements  representatives  who  ensure  inclusion  of  civil 
requirements  in  GPS  CDDs.  USSTRATCOM  is  a  cross-service  organization  that 
ensures  it  can  provide  direction  to  the  operators  of  the  GPS  with  Space  Tasking 
Orders  (STOs).  These  STO  messages  direct  operators  to  include  commands  in 
the  navigation  message  that  change  the  behavior  of  the  GPS  in  a  theater  of 
operations  and  benefit  military  users.  The  requirements  levied  by  these 
organizations  are  now  scrutinized  by  the  Joint  Requirements  Oversight  Council 
(JROC). 

The  GPS  cannot  exist  as  a  useful  system  without  the  contributions  of 
various  organizations.  These  include  the  Air  Force  Weather  Agency  (AFWA), 
which  tracks  solar  flares  that  affect  the  transmission  of  GPS  signals.  Also 
noteworthy  are  the  National  Geospatial  Intelligence  Agency  (NGA)  mentioned  in 
section  B2  above  and  the  National  Security  Agency  (NSA)  mentioned  in  section 
A  above.  The  United  States  Naval  Observatory  (USNO)  provides  another 
atomic-based  time  reference  against  which  to  compare  GPS  time.  The 
Joint  Space  Operations  Center  (JSpOC)  has  an  interface  with  the  GPS  for 
receiving  GPS  data  in  a  particular  format. 

Lastly,  the  GPS  inherits  technical  requirements  and  constraints  as  a  result 

of  the  regulatory  environment  and  agreements  reached  between  the  U.S.  and 

other  nations.  These  regulations  and  agreements  encompass  a  range  of 
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concerns  such  as  military  interests,  compatibility — the  degree  to  which  there  is  or 
is  no  harmful  interference)  between  two  radio  frequency-based  systems,  and 
even  the  definition  of  signal  characteristics  for  possible  common  use  in  other 
Radio  Navigation  Satellite  Systems  (RNSSs)  that  could  work  with  GPS. 

The  GPS  Wing  considers  all  proposed  requirements  and  changes  with  the 
requirements  management  process.  This  process  requires  a  great  deal  of 
interaction  among  the  different  stakeholders  represented  within  the  GPS 
program.  The  next  section  describes  this  process. 

3.  The  GPS  Requirements  Management  Process 

The  requirements  management  process  requires  that  the  Systems 
Engineering  Division  consider  the  technical  implications  of  adopting  or  changing 
requirements.  Because  of  schedule  and  cost  impacts  that  can  result  to  the 
programs’  segment  development  contracts,  this  division  cannot  make  decisions 
without  coordinating  with  product  development  and  functional  groups.  Figure  6 
shows  the  internal  program  interaction  that  occurs  before  a  decision  to 
rebaseline  the  GPS  program’s  requirements.  This  interaction  is  designed  to  work 
through  the  system’s  Configuration  Control  Board  (CCB)  to  coordinate  all 
requirements  baseline  changes.  All  affected  stakeholders  contribute  to  the 
decision  made  through  the  CCB. 

The  Systems  Engineering  Division  performs  much  of  the  requirements 
analysis  necessary  to  foster  productive  discussions  about  new  requirements  with 
the  other  stakeholders.  This  analysis  includes  eliciting,  collecting,  developing, 
and  verifying  customer  and  other  stakeholder  requirements  before  translating 
these  into  possible  GPS  segment  development  program  requirements.  The 
Engineering  Review  Board  (ERB)  is  the  forum  for  discussion  within  the  Systems 
Engineering  Division  that  occurs  before  forwarding  proposed  requirements 
(including  changes)  to  a  system  CCB  to  involve  the  other  program  facets  in  the 
decision  regarding  whether  and/or  how  best  to  implement  a  new  requirement  or 
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requirement  change.  The  ERB  rejects  proposed  changes  to  the  program 
technical  baseline  if  these  proposals  require  more  analysis  before  CCB 
consideration. 


•Technical  •Reliability  •Usability  Board  (ERB) 

•Performance  •Security 

Figure  6.  GPS  Wing  Requirements  Management  Process  (After  Chief  Engineer 

Navstar  GPS  Joint  Program  Office,  2006a,  2006c) 


Segment  development  programs  will  often  propose  changes  to 
requirements  for  a  few  reasons.  Not  only  does  the  GPS  Wing  have  the  ability  to 
change  requirements,  but  the  vendors  who  control  some  of  the  interface 
definitions  also  have  this  ability.  There  may  be  technical  challenges  that  are  too 
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difficult  or  costly  to  overcome  in  the  scheduled  amount  of  time.  Also,  segment 
program  requirements  usually  change  through  testing  phases.  Sometimes  it  is 
easier  to  change  requirements  than  it  is  to  satisfy  them.  This  approach  is 
beneficial  when  analysis  reveals  that  the  benefit  of  changing  a  requirement 
outweighs  the  cost.  This  can  occur  from  a  perspective  of  achieving  a  level  of 
overall  system  performance,  but  may  occur  in  the  context  of  shifting  the  relative 
burden  of  satisfying  a  requirement  from  one  segment  to  another.  Vendors  may 
propose  such  changes  if  in  their  own  respective  interests  without  regard  for  the 
best  interests  of  the  GPS  program.  If  implemented,  the  vendor  responsible  for 
the  other  side  of  the  interface  would  need  to  accommodate  changes  to  interface 
requirement,  and  such  an  impact  would  have  costs  that  the  government  would 
have  to  cover.  More  broadly,  shifting  any  requirements  via  the  CCB  can  have 
contractual  impacts  that  the  Contracts  Division  must  provide  as  direction  to  the 
appropriate  vendors  to  implement. 

Direction  to  vendors  is  likely  to  have  cost  impacts  on  the  development 
contracts,  and  all  cost  impacts  require  coordination  with  the  Program  Control 
Division.  Not  surprisingly,  technical  and  schedule  changes  have  impacts  on 
contracts  that  obligate  the  program  to  cover  any  costs.  Thus,  the  Program 
Control  Division  finds  itself  coordinating  with  the  other  GPS  Wing’s  organizations 
to  ensure  that  the  program  can  meet  proposed  obligations  before  committing  to 
requirements  baseline  changes  that  the  Wing  cannot  implement  within  schedule 
and  budget  constraints.  Segment  development  program  managers  help  to 
assess  the  cost,  schedule,  and  technical  impacts  to  their  respective  programs  as 
a  result  of  proposed  changes. 

E.  IDENTIFIED  RISKS  AND  CONCERNS 

There  are  forces  that  affect  the  ability  of  the  GPS  Wing  to  execute  its 
development  programs.  Customers,  operators,  and  users  expect  programs  to 
remain  on  schedule  and  deliver  promised  capabilities.  On  the  other  hand, 
ambitious  and  perhaps  unrealistic  schedules  increase  the  risk  of  program  failure. 
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Loosely  written  contracts  during  Acquisition  Reform  era  of  the  mid-1990s  also 
limit  the  government’s  ability  to  govern  the  execution  of  current  contracts.  As  the 
GPS  Wing  tries  to  recover  from  the  development  problems  of  these  programs, 
customers  disregard  past  experience  and  continue  to  set  high  expectations  for 
the  Block  III  subsystem  programs’  cost,  schedule,  and  technical  successes. 

1.  Pressures  from  Customers,  Operators,  and  Users 

As  a  joint  military  and  international  civil  resource,  the  GPS  attracts  a 
tremendous  amount  of  interest.  It  is  a  high-value  and  complex  system  that  has 
provided  PVT  information  for  nearly  two  decades,  and  yet  it  is  also  under 
continuous  development.  Unfortunately,  development  has  proceeded  unevenly 
across  GPS  Segments.  As  the  Block  III  satellite  development  proceeds,  the  lag 
in  Control  Segment  development  may  continue  due  to  unrealistic  schedules  and 
incomplete  requirements.  The  first  increment  of  the  Block  III  Control  Segment 
will  implement  only  the  capabilities  available  on  the  Block  IIA,  HR,  IIR-M,  and  IIP 
capabilities.  Block  III  satellite  operations  will  not  be  possible  until  the  second  of 
four  increments.  Furthermore,  there  is  a  desire  to  accelerate  the  launch  of  the 
first  increment  of  GPS  III  satellites,  which  would  require  the  implementation  of  the 
second  increment  of  the  Block  III  Control  Segment  increment  within  two  years 
from  contract  award.  While  the  requirements  definition  has  not  finished  and  the 
issuance  of  an  RFP  is  already  behind  schedule,  there  is  a  push  to  have  the  RFP 
issued  by  December  2006. 

These  external  pressures  are  setting  the  Block  III  Control  Segment 
program  up  for  future  difficulties.  It  is  not  realistic  to  expect  a  five-fold  increase  in 
speed  between  contract  award  and  operational  capability  without  solid  and 
complete  requirements.  It  is  more  likely  that  requirements  problems  will  prevent 
the  Block  III  Control  Segment — and  probably  the  Block  III  Space  Segment 
program  as  well — from  adhering  to  their  schedules.  A  lack  of  complete  and  well- 
defined  requirements  will  probably  cause  integration  problems  as  well.  The 
outcome  may  be  the  continuation  of  the  Control  Segment  lag  that  is  evident  in 
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Figure  5’s  split  arrows  through  the  System  Engineering  box,  which  show  that  the 
implementation  of  some  requirements  in  the  SORD  and  ORD  occur  in  the 
following  blocks’  subsystems.  If  this  pattern  continues,  the  GPS  program  will  not 
implement  some  Block  III  requirements  until  Block  IV. 

Block  III  Control  Segment  and  Space  Segment  successes  are  necessary 
to  satisfy  the  needs  of  customers  and  users.  Without  availability  of  the  Block  III 
satellites  and  the  second  increment  of  the  Block  III  Control  Segment,  the  GPS 
Wing  will  not  be  able  to  sustain  GPS  constellation.  If  GPS  Wing  anticipates  an 
inability  to  reach  the  milestones  for  these  two  deliverables  before  launching  all 
Block  IIF  satellites,  the  fallback  contingency  would  require  the  acquisition  of  more 
of  these  satellites  before  the  production  line  shuts  down.  Users  would  have  to 
experience  the  wait  for  new  capabilities  again,  and  the  GPS  Wing  would  need  to 
reallocate  near-term  funds  for  the  purchase  of  more  Block  IIF  satellites  rather 
than  apply  them  to  Block  III  contracts. 

2.  Transition  to  an  Entireiy  New  Controi  Segment 

For  the  first  time  in  its  operation,  the  program  is  planning  the  most 
significant  transition  in  the  system’s  history  that  involves  the  replacement  of  the 
Control  Segment’s  hardware  and  software  in  order  to  prepare  for  the  addition  of 
new  capabilities.  This  immense  technical  challenge  includes  the  daunting  risk 
that  something  might  not  work  correctly,  thereby  requiring  the  current  system  to 
serve  as  a  back-up  to  prevent  an  interruption  of  service.  The  program  has  never 
faced  a  challenge  that  places  the  operation  of  the  entire  system  at  such  risk. 
Previous  challenges  dealt  with  new  block  versions  of  satellites  where  the 
technical  failure  of  a  single  satellite  still  left  the  GPS  Wing  with  time  to  recover 
prior  to  the  next  launch.  In  order  to  mitigate  schedule  and  constellation 
replenishment  risk  further,  current  launch  practices  have  the  Wing  hold  a 
previous  version  of  satellite  in  reserve  after  launching  the  first  new  version  of 
satellite.  The  Control  Segment  does  not  have  this  luxury  because  the  Block  IIF 
New  Master  Control  Station  (NMCS)  must  be  ready  to  support  the  operation  of 
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Block  IIF  satellites.  Readiness  depends  on  operator  confidence  in  this  system, 
because  if  the  operators  are  not  confident  that  it  will  function  properly,  they  will 
not  accept  the  new  system.  At  the  same  time,  the  legacy  MCS  will  not  be  able  to 
command  and  control  the  new  Block  IIF  satellites — if  needed  as  a  backup,  the 
MCS  would  only  be  able  to  sustain  the  pre-Block  IIF  satellite  constellation. 

The  GPS  Wing  already  faces  a  tough  financial  climate  after  dealing  with  a 
past  oversight  that  resulted  in  a  lack  of  vendor  support  for  the  transition  of  NMCS 
hardware  and  software  to  operational  use.  The  increase  in  the  Block  IIF  contract 
scope  to  include  Control  Segment  transition  support  cost  the  Wing  precious 
funds.  The  vendor  for  the  Block  III  Control  Segment  should  expect  to  satisfy 
requirements  for  transition  activities  also. 

3.  Contractual  Challenges  for  the  Space  and  Control  Segments 

The  GPS  operators  were  expected  to  command  and  control  the  GPS 
constellation  using  the  NMCS  before  the  turn  of  the  millennium.  The  Block  IIF 
contract  designated  the  vendor  as  the  single  prime  contractor  and  system 
integrator  for  its  Space  Segment  and  Control  Segment  deliverables.  However, 
the  vendor  does  little  integration  work  as  it  attempts  to  overcome  technical  and 
schedule  challenges  for  both  major  sets  of  deliverables. 

Operators  were  also  expected  to  take  on  new  responsibilities  for  the 
Launch,  Anomaly  Resolution,  and  Disposal  Operations  (LADO)  subsystem  that 
will  replace  a  cross-program  system  that  was  to  be  decommissioned  already. 
The  GPS  Wing  must  now  fund  the  operation  of  this  older  system  alone  because 
other  satellite  programs  have  ended  their  reliance  on  it  and  because  the  GPS 
Wing  has  yet  to  overcome  its  LADO  subsystem  development  program 
challenges.  Problems  with  ambiguous  requirements  have  caused  problems  with 
design  and  coding,  as  well  as  with  the  verification  of  these  unclear  requirements. 

Complicating  matters  more  for  the  GPS  Wing,  the  Block  NR  satellite 
vendors  find  that  they  need  to  make  changes  to  satellite  flight  software  that 
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would  make  it  incompatible  with  Block  I  IF  Control  Segment  software  undergoing 
test  and  evaluation.  It  would  have  been  simpler  and  cheaper  to  modify  the 
Control  Segment  software  when  the  system  was  delivered  and  operational.  An 
additional  risk  involves  the  loss  of  Block  HR  satellite  vendor  corporate  knowledge 
if  that  vendor  must  delay  fight  software  modifications  long  enough  to  necessitate 
laying-off  key  technical  personnel.  These  people  may  find  other  programs  or 
employers  to  support.  After  the  Block  I  IF  Control  Segment  becomes  operational, 
the  Block  HR  satellite  vendor  also  might  not  be  available  via  an  active  contract  to 
work  with  Control  Segment  Support  Division  personnel  to  improve  the  interface 
between  their  subsystems. 

F.  CHAPTER  SUMMARY 

This  chapter  summarizes  the  basic  functions  of  the  Global  Positioning 
System  (GPS)  and  its  segments,  and  describes  the  breadth  of  stakeholders  who 
have  an  interest  in  the  system.  It  also  describes  the  organization  of  the  GPS 
Wing  that  includes  an  expanded  description  of  the  Systems  Engineering  Division 
and  the  Branches  within  that  division  that  are  responsible  for  various  types  of 
requirements  engineering  activities.  These  activities  include  the  requirements 
engineering  activities  that  involve  the  system  stakeholders  and  the  requirements 
documentation  they  influence,  as  well  as  the  GPS  Wing  requirements 
management  process.  The  Acquisition  Program  Baseline  (APB)  highlights  the 
relationships  between  subsystem  development  programs  and  the  capabilities 
that  they  promise.  As  this  chapter  concludes,  these  subsystem  development 
programs  have  not  progressed  as  envisioned,  and  there  are  several 
requirements  integration  issues  that  the  program  must  address  in  order  to  deliver 
working  subsystems  and  capabilities  without  further  significant  costs,  delays,  and 
technical  challenges. 
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III.  LITERATURE  REVIEW 


A.  INTRODUCTION 

This  chapter  discusses  GPS  program  requirements  literature,  and  other 
requirements  engineering  literature  that  influences  the  GPS  program’s  handling 
of  its  requirements.  Because  there  are  so  many  requirements  sources  that 
impact  the  GPS’s  development  over  its  growing  number  of  block  upgrades,  this 
chapter  offers  only  a  sample  of  GPS  program  requirements  documents.  This 
sample  includes  the  Capabilities  Development  Document  (CDD)  provided  by  the 
GPS  Wing’s  customers;  the  most  recent  System  Specification  (SYS)  written  by 
the  GPS  Wing;  one  of  many  Interface  Control  Documents  (ICDs)  and  Interface 
Specifications  (ISs),  and  requirements  management  guidance  in  the  form  of  GPS 
Wing  Operating  Instructions  (Ols).  Other  resources  include  guidance  from  the 
Software  Technology  Support  Center  (STSC)  and  technical  documentation  for 
the  Dynamic  Object-Oriented  Requirements  System  (DOORS)  database. 


B.  ORGANIZATIONAL  LITERATURE 

1.  Overview  of  GPS  Requirements  Sources 

GPS  requirements  sources  are  those  documents  and  organizations 
identified  in  Figure  5  of  Chapter  II.  These  include  the  CDD  and  its  predecessor 
documents,  the  ORD  and  SORD,  as  well  as  the  hierarchy  of  specifications  and 
ICDs  that  apply  either  to  the  overall  system  or  to  specific  components  of  its 
segments  such  as  a  block  of  satellites.  Other  documentation  that  affects 
requirements  development,  management,  and  verification  are  GPS  Operating 
Instructions  (Ols).  Two  operating  instructions  are  of  particular  interest  to  this 
research  effort:  the  DOORS  OI  and  the  Requirements  OI  exist  only  in  draft  form 
as  of  September  22,  2006. 
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2.  Capabilities  Development  Document  (CDD)  for  the  Block  III 
Space  and  Control  Segments 

The  Capabilities  Development  Document  will  be  a  compliance  document 
for  the  GPS  Block  III  space  and  control  segment  contracts.  This  440-page 
document  signed  by  the  4-Star  military  leaders  of  Air  Force  Space  Command 
(AFSPC)  and  the  Fleadquarters  U.S.  Air  Force  (HQ  USAF)  presents  system 
conceptual  descriptions  and  gaps  in  capabilities  that  development  efforts  should 
close.  Covered  in  the  first  section,  Capabilities  Discussion,  these  gaps  are 
measured  by  comparing  different  environmental  conditions  in  which  the  GPS 
might  operate.  Whereas  the  GPS  operated  effectively  in  non-hostile 
environments  and  those  that  existed  during  past  military  operations, 
environmental  conditions  have  become  less  hospitable  and  the  effectiveness  of 
the  GPS  services  has  deteriorated  accordingly.  For  example,  the  increase  in 
non-GPS  civil  users  of  the  frequency  spectrum  has  adversely  impacted  civil 
users  of  GPS.  Military  users  have  also  operated  in  environments  that  included 
harmful  sources  of  interference  to  GPS.  To  overcome  these  challenges  to 
operational  capability  effectiveness,  the  CDD  serves  to  identify  the  highest 
system-level  requirements  that  the  GPS  Wing  will  need  to  satisfy  through  its 
development  programs.  This  CDD  covers  the  subject  areas  shown  in  Table  2. 
The  paragraphs  that  follow  note  the  main  themes  in  how  requirements  are  stated 
throughout  this  CDD,  but  do  not  discuss  specific  requirements  themselves. 
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•  Capability  Discussion 

•  Analysis  Summary 

•  Concept  of  Operations 
(CONORS)  Summary 

•  System  Capabilities 
Required  for  the  Current 
Increment 

•  Program  Summary 

•  Family  of  System  and 
System  of  Systems 
Synchronization 

•  Electromagnetic 
Environmental  Effects  (E3) 
and  Spectrum 
Supportability 

•  Schedule  and  lOC/FOC 
Definitions 


•  Threat  Summary 

•  National  Security  System 
and  Information  Technology 
System  (NSS  and  ITS) 
Supportability 

•  Intelligence  Supportability 

•  Assets  Required  to  Achieve 
Initial  Operational  Capability 

•  Other  Doctrine,  Organization, 
Training,  Materiel, 

Leadership  and  Education, 
Personnel,  and  Facilities, 
(DOTMLPF)  Considerations 

•  Other  System  Characteristics 

•  Program  Affordability 


Table  2.  GPS  III  CDD  Subject  Areas 


The  Analysis  Summary  section  discusses  results  and  scores  for  various 
capability  solution  alternatives.  While  some  of  the  results  discussed  come  from 
testing  or  simulation,  subject  matter  experts  relied  on  their  experience  to  specify 
other  results  subjectively.  This  comparative  analysis  is  interesting  and  perhaps 
useful  to  a  vendor  who  would  like  to  understand  the  rationale  for  some 
requirements — especially  when  requirements  suggest  a  specific  combination  of 
technologies  to  be  developed  further  in  order  to  provide  a  capability.  However, 
the  analysis-of-alternatives  discussions  do  not  introduce  clear  requirements  to 
satisfy.  Instead,  recommendations  keep  the  government’s  options  open 
regarding  how  it  will  eventually  define  requirements.  These  recommendations 
include  mention  of  the  needs  to  conduct  further  analyses,  which  means  that  it  is 
up  to  the  Wing  to  develop  the  high-level  requirements  for  the  areas  analyzed. 
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The  CONORS  Summary  explains  what  the  customers  and  operators  want 
in  terms  of  the  logical  and  physical  architecture  of  the  system  that  the  GPS  Wing 
will  deliver.  With  the  CDD  as  a  compliance  document,  these  expectations 
become  real  requirements.  If  the  delivered  system  does  not  conform  to  the 
CONORS,  the  customers  and  operators  will  declare  the  system  to  be 
operationally  unsuitable,  which  in  turn  would  result  in  the  failure  of  the 
development  program.  In  addition  to  this  CONORS  Summary,  there  is  an 
appendix  to  the  CDD  that  expands  on  the  GPS  architecture  with  the  All  Views, 
Operational  Views,  and  System  Views  of  the  Department  of  Defense  Architecture 
Framework  (DoDAF). 

Requirements  in  the  CDD  are  stated  in  terms  of  operational  effect  of  the 
overall  GPS.  For  example.  Key  Performance  Parameters  (KPPs)  specify  levels 
of  PVT  accuracy  in  units  of  meters,  and  availability  of  these  levels  of  service  in 
terms  of  percentages  of  time.  Failure  for  a  program  to  achieve  a  KPP  could 
result  in  a  decision  to  terminate  that  program.  Many  KPP  values  and  system 
Threshold  and  Objective  performance  targets  are  defined  in  the  78-page  CDD 
section  titled  System  Capabilities  Required  for  the  Current  Increment.  This 
section  includes  quantifiable  measures  of  system  performance  and  rationale  for 
the  numbers  chosen.  The  rationale  can  be  useful  to  developers  and  customers 
alike  as  development  of  any  part  of  the  system  continues  and  questions  arise 
about  the  importance  of  achieving  these  goals.  While  some  rationale  explains 
operational  needs,  other  rationale  describes  constraints  in  the  form  of  laws  or 
regulations  that  may  change  over  time  and,  as  a  result,  influence  future  program 
decisions. 

There  are  many  requirements  that  the  GPS  must  satisfy  in  order  to  remain 
interoperable  with  external  systems,  or  that  other  DoD  systems  must  also  satisfy. 
These  are  identified  in  the  Family  of  System  and  System  of  Systems 
Synchronization  section.  Cross-DoD  system  requirements  for  Families  of 
Systems  are  specified  in  Capstone  Requirements  Documents  (CRDs)  that  cover 
the  areas  of  interest  identified  in  the  following  titles: 
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•  Close  Air  Support  (CAS) 

•  Combat  Identification  (CID) 

•  Global  Air  Traffic  Management  (GATM) 

•  Global  Information  Grid  (GIG) 

•  Integrated  Satellite  Operations  (SATOPS) 

•  Space  Control. 

These  CRDs  are  compliance  documents  for  the  GPS  program  that  cover  various 
system  functional  and  nonfunctional  requirements.  Each  of  the  CRDs  represents 
a  Family  that  the  GPS  belongs  to.  System  of  Systems  include  augmentation 
systems  and  additional  payloads  for  the  GPS.  Desired  interoperability  with 
space-based  and  ground-based  GPS  augmentation  systems  is  important  to 
support  the  improvement  of  GPS  accuracy  for  civil  users.  The  GPS  also  meets 
requirements  to  support  the  implementation  of  the  non-PVT  service  known  as  the 
Nuclear  Detonation  (NUDET)  Detection  System  (NDS),  and  may  need  to  add 
requirements  to  support  capabilities  desired  in  the  concept  known  as  the  Distress 
Alerting  Satellite  System  (DASS). 

The  Electromagnetic  and  Environmental  Effects  fE3)  and  Spectrum 
Supportability  section  is  noteworthy  because  of  its  simplicity  and  brevity.  This 
section  requires  that  subsystems  in  both  the  Space  and  Control  Segments  be 
able  to  operate  effectively  in  their  respective  electromagnetic  environments.  It 
also  requires  that  the  GPS  operate  in  compliance  with  both  the  ever-changing 
international  and  domestic  regulations  and  policies  that  govern  frequency 
spectrum  use.  Therefore,  it  is  most  practical  to  cite  these  requirements  by 
reference  and  omit  discussion  of  goals  and  rationale. 

The  section  titled  Schedule  and  lOC/FOC  Definitions  appears  to  contain 
no  requirements,  but  in  a  document  called  a  “Capabilities  Development 
Document,”  it  seems  appropriate  that  some  terms  related  to  these  capabilities 
are  defined  in  order  to  facilitate  the  statement  of  requirements  within  or  beyond 
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the  CDD.  Of  particular  interest  to  GPS  program  managers,  system  engineers, 
customers,  operators  and  users  are  the  definitions  of  Initial  Operational 
Capability  (IOC)  and  Full  Operational  Capability  (FOC).  These  definitions 
depend  on  the  implementation  of  technologies  in  all  three  GPS  segments. 

While  describing  system-related  requirements,  several  sections  also 
include  development-related  requirements  that  are  not  requirements  that  the 
operational  GPS  would  need  to  satisfy.  These  requirements  are  appropriate  for 
a  capabilities  document  that  guides  system  development.  Some  of  these,  like 
Threat  Summary  and  the  Supportability  sections  describe  issues  that  are 
important.  These  nonfunctional  requirements  issues  cover  system  technical 
characteristics,  performance,  reliability,  security,  and  usability.  These  sections 
are  as  follows: 

•  Threat  Summary 

•  National  Security  System  and  Information  Technology  System 

(NSS  and  ITS)  Supportability 

•  Intelligence  Supportability 

•  Assets  Required  to  Achieve  Initial  Operational  Capability 

•  Other  Doctrine,  Organization,  Training,  Materiel,  Leadership  and 

Education,  Personnel,  and  Facilities,  (DOTMLPF)  Considerations 

•  Other  System  Characteristics,  such  as 

o  Flazardous  Materials 

o  Safety  and  Flealth 

o  Security  Classification  Guidance 

•  Program  Affordability 

These  sections  include  system  requirements,  especially  in  the  case  of  personnel 
and  facilities  that  are  critical  parts  of  the  Control  Segment.  Many  of  the  types  of 
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requirements  in  these  sections  include  threshold  values  that  equal  their  objective 
values,  thereby  showing  that  the  requirements  are  either  satisfied  or  they  are  not. 


3.  System  and  Segment  Specifications 

The  specifications  documents  focus  on  system  and  subsystem 
requirements  that  support  the  delivery  of  a  subset  of  required  capabilities 
described  in  the  CDD.  These  documents  are  different  than  the  CDD  in  their 
organization  and  their  focus.  They  contain  a  more  detailed  view  of  the  system, 
its  performance,  and  the  specific  user  needs  to  be  satisfied.  System 
Specifications  (SYS)  and  Segment  Specifications  (SS)  are  similar  in  their 
structure.  A  description  of  the  Space  and  Control  System  Specification  follows 
below. 

In  order  to  avoid  redundancy,  the  GPS  III  Space  and  Control  Segment’s 
System  Specification  names  103  other  requirements  documents  as  sources  of 
requirements  that  must  be  satisfied.  These  sources  include  the  following  items: 

•  DoD  Handbooks  and  Standards 

•  Air  Force  Directives,  Instructions,  Manuals,  and  Pamphlets 

•  DoD  Directives,  Instructions  and  Manuals 

•  GPS  Wing  Documents  (ICDs,  ISs,  the  Program  Protection  Plan, 
and  Computer  Resource  Support  Plan) 

•  GPS  Modernization  System  Threat  Assessment  Report  (STAR) 

•  Agreements  with  federal  agencies  and  international  organizations 

•  Miscellaneous  aviation,  frequency  spectrum,  acquisition,  safety, 
security,  design,  test,  certification,  and  operational  guidelines  and 
standards 

•  Specifications  and  reference  documents  from  other  agencies  and 
programs 
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These  documents  fall  into  two  categories:  1)  compliance  documents  that  are  to 
be  treated  as  an  extension  of  the  SYS,  and  2)  reference  documents  that  can  act 
as  guides  or  sources  of  other  relevant  information.  To  prevent  any  problems  with 
requirements  ambiguity,  the  SYS  states  that  its  guidance  supersedes  any 
requirements  that  are  in  conflict  with  the  SYS.  Lower  tier  requirements  (below 
the  CDD)  comply  with  the  following  order  of  precedence: 

1 .  System  Specification  (SYS) 

2.  Segment  Specification  (SS) 

3.  System-Level  Interface  Control  Documents  (ICDs)  and  Interface 

Specifications  (ISs) 

4.  Segment  Product/Development  Specifications 

A  brief  system  description  section  describing  the  functions  and  capabilities 
of  the  next  generation  Space  and  Control  Segments  precedes  the  discussion  of 
GPS  III  system-level  requirements  that  contain  ‘shalf  statements.  Even  though 
this  SYS  is  not  a  User  Segment  specification,  it  describes  system  performance  in 
terms  that  are  relevant  to  user  equipment  measurements  like  pseudorange  and 
calculations  like  PVT  information.  Requirements  statements  also  address  other 
user  concerns,  such  as  the  level  of  availability  of  GPS  services.  For  services  that 
do  not  exist,  effectivity  is  used  to  help  describe  the  incremental  deployments  of 
capabilities  in  the  SYS.  For  both  the  Space  and  Control  Segments,  there  are 
four  effectivities,  or  increments,  defined  in  this  SYS.  Only  the  final  full- 
capabilities  effectivity  definition  for  each  of  these  two  Segments  matches. 
Because  the  Control  Segment’s  subsystem  is  not  up  to  date,  the  first  Block  III 
Control  Segment  increment  addresses  only  unsatisfied  requirements  from  the 
ORD  that  the  CDD  absorbed. 

In  addition  to  increasing  the  breadth  and  quality  of  services,  the  GPS  must 
also  continue  providing  the  current  services.  In  order  to  do  so,  new  parts  of  the 
GPS  Segments  must  maintain  the  current  external  interfaces,  and  either  replace 
or  continue  to  support  internal  interfaces  with  existing  Segment  subsystems.  The 
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GPS  has  external  interfaces  with  additional  GPS  satellite  payloads  and  systems 
that  belong  to  non-AFSPC  organizations  like  those  described  in  Figure  5.  GPS 
internal  interfaces  connect  the  various  GPS  Space  Segment  vehicles  with  each 
other,  the  Control  Segment,  and  the  User  Segment. 

The  remaining  requirements  are  nonfunctional  and  address  the  following 
areas  of  concern: 


•  Safety 

•  Security 

•  Computer 

•  Environmental 

•  Quality 

•  Design  &  Construction 

These  are  all  important  nonfunctional 
successful  fielding  of  new  capabilities. 


•  Personnel 

•  Training 

•  Logistics 

•  Packaging,  handling, 
storage,  and  transportation 

requirements  that  have  an  impact  on  the 


A  Quality  section  discusses  the  methods  for  verification  of  requirements  to 
ensure  that  the  system  will  meet  its  performance  criteria,  comply  with  design 
characteristics,  satisfy  interface  needs,  and  operate  properly.  System  Engineers 
and  Program  Managers  can  verify  requirements  using  the  following  methods  to 
be  tracked  for  each  requirement  in  the  DQQRS  requirements  database: 


•  Inspection 

•  Analysis 

•  Demonstration 

•  Test 

•  Special  methods  to  provide  aviation  safety  assurance. 
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The  government  specification  documents  often  use  the  word  shall,  but 
there  is  no  current  government  source  that  restricts  the  use  of  this  word  or 
defines  what  it  means  when  compared  to  other  words  like  must  and  will. 
Vendors  find  it  necessary  to  provide  definitions  for  these  terms  in  order  to 
prevent  any  conflicts  from  arising  about  their  meanings.  At  the  beginning  of  its 
software  requirements  specifications  (SRSs)  written  under  contract  for  Boeing 
Navigation  Systems,  Lockheed  Martin  Integrated  Systems  and  Solutions 
(Gaithersburg,  MD)  provides  definitions  that  are  paraphrased  below: 

•  A  ‘shall’  statement  identifies  all  requirements  or  parts  of 
requirements  that  trigger  design,  coding/production,  and  unless  otherwise 
stated,  testing.  A  ‘shall’  statement  has  a  unique  number  for  identification 
and  traceability. 

•  A  ‘must  statement  identifies  a  requirement  that  is  one  of  two  things: 
o  a  system  design  constraint 

or 

o  a  provision  being  provided  to  the  designer  by  the 
government  and  upon  which  the  designer  depends-government 
furnished  property  (GFP)  or  equipment  (GFE). 

•  A  ‘will’  statement  is  used  like  a  ‘must’  statement  for  instances  in 
which  the  government  is  to  provide  GFP  or  GFE,  but  the  system  being 
designed  does  not  depend  on  this  property  or  equipment. 

Because  there  is  no  need  for  unique  identification  or  traceability,  ‘must 
and  ‘will’  statements  are  not  numbered. 

4.  Interface  Control  Documents  (ICDs)  and  Interface 
Specifications  (ISs) 

GPS  program  uses  ICDs  and  ISs  to  describe  the  interfaces  between  GPS 
subsystems.  There  are  external  interfaces  with  systems  belonging  to  other 
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organizations,  and  there  are  internal  interfaces  that  describe  the  characteristics 
of  the  information  exchanged  between  different  GPS  Segments’  subsystems. 
Dozens  of  these  ICDs  and  ISs  describe  internal  interfaces,  and  while  the 
government  controls  some  of  these  interface  documents,  contractors  exercise 
control  over  others.  This  section  discusses  the  government-vendor  conflict  over 
these  documents,  and  describes  the  structure  of  one  of  the  interface  documents. 

a.  The  Emergence  of  ISs  in  the  GPS  Wing 

Current  practice  establishes  the  Interface  Control  Contractor  (ICC) 
for  a  given  ICD  as  one  of  the  vendors  for  two  new  subsystems  that  will  interface. 
For  example,  an  ICD  describes  the  interface  between  the  Block  I  IF  Control 
Segment  and  the  Block  HR  satellites.  The  Block  HR  satellite  vendor  is  the  ICC 
for  this  interface.  Problems  with  ICC  control  over  ICDs  prompted  changes  to 
how  the  GPS  Wing  baselines  interface  descriptions.  As  a  result  of  these 
problems,  a  previous  GPS  Wing  Commander  decided  to  change  how  the  GPS 
Wing  handled  certain  interface  documents. 

Vendors  took  exception  to  changes  proposed  for  ICDs  that 
described  GPS  signals.  Because  ICDs  require  the  affected  parties  to  agree  to 
changes,  and  agreement  requires  that  the  parties  provide  their  signatures  on 
Interface  Revision  Notices  (IRNs),  the  lack  of  vendor  signatures  on  these  ICDs 
prevented  the  GPS  program  from  implementing  necessary  changes  to  signal 
descriptions.  The  GPS  Wing  Commander  attempted  to  regain  control  over  these 
ICDs  by  changing  the  names  of  these  documents  to  Interface  Specifications  and 
treating  them  the  way  that  the  Air  Force  Satellite  Control  Network  (AFSCN)  treats 
its  own  ISs — the  AFSCN  issues  changes  to  ISs  without  ensuring  that  the  affected 
parties  approve  of  the  changes  (Alexander,  P.,  personal  communication,  August 
31,  2006).  In  the  case  of  the  AFSCN,  it  is  infeasible  to  gain  approval  from  all 
affected  parties  because  there  are  so  many.  The  GPS  Wing  Commander 
implemented  the  same  approach  by  arranging  for  some  ICDs  to  become  ISs 
because  it  is  also  impractical  to  get  the  approval  of  so  many  GPS  users  when 
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changing  ICDs  might  affect  them.  The  GPS  Wing  Commander  argued  that  if 
users  did  not  provide  their  consent  to  ICD  changes,  then  vendors  would  not  need 
to  consent  to  interface  changes  either.  Therefore,  ICDs  describing  the  interface 
between  one-subsystem  and  many  affected  parties  became  ISs.  The  structure 
of  an  IS  is  the  same  as  that  for  an  ICD.  ICDs  continue  to  describe  one-to-one 
interfaces  and  require  signatures  from  each  of  the  two  affected  parties  when 
there  is  an  agreement  on  changes. 

The  emergence  of  ISs  in  the  GPS  Wing  did  not  solve  all  contractual 
problems  with  vendors.  The  GPS  Wing  found  it  necessary  to  include  ‘shall’ 
statements  in  ICDs  and  ISs  so  that  vendors  would  ensure  that  their  deliverables 
would  interface  with  existing  GPS  subsystems  properly.  Without  ‘shall’ 
statements  in  interface  documents  that  require  verification  testing,  vendors 
considered  such  testing  to  be  beyond  the  scope  of  their  contracts.  Instead  of 
defining  and  describing  interfaces  with  the  least  amount  of  ambiguity  possible — 
perhaps  by  offering  detail  and  background  information — GPS  program  ICDs  and 
ISs  go  beyond  providing  descriptions  by  stating  requirements  for  vendors  to 
satisfy.  According  to  SETA  contractor  Patricia  Alexander,  “good  old  engineering 
common  sense  should  lead  to  verification  tests,”  but  without  a  ‘shall’  statement, 
the  vendors’  business  managers  will  not  agree  to  verify  that  their  deliverables  will 
interface  with  other  GPS  subsystems  correctly  (Alexander,  P.,  personal 
communication,  August  31 ,  2006). 

b.  Space-to-User  Interface  Specification 

SETA  contractor  ARINC  is  the  ICC  for  the  IS  that  describes  the 
interface  between  the  Space  Segment  and  the  GPS  navigation  users  who  belong 
to  the  User  Segment.  Because  this  document  is  for  an  internal  interface,  there 
are  no  external  specifications  or  standards  that  apply.  This  document  focuses  on 
Space-to-User  requirements  exclusively. 

This  IS  describes  the  carrier  frequency,  ranging  code,  signal 

structures,  navigation  signal,  and  other  signal  characteristics  of  interest  to  two 
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important  categories  of  GPS  stakeholders  who  work  with  their  GPS  Wing 
counterparts:  1)  user  equipment  developers  who  must  process  GPS  signals,  and 
2)  satellite  developers  who  must  provide  the  signals.  In  addition,  there  are  also 
many  definitions  and  equations  provided  to  ensure  a  common  understanding 
among  these  two  groups  of  stakeholders  so  that  they  develop  subsystems  that 
are  compatible.  Going  beyond  the  description  of  the  interface,  there  are  several 
‘shall’  statements  in  this  document  that  require  both  interfacing  subsystems  to 
support  specified  levels  of  service. 

As  a  result  of  changes  to  this  IS,  vendors  submitted  Letters  of 
Exception  (LOEs)  to  state  their  non-concurrence  with  proposed  changes  that 
became  approved.  Even  though  the  GPS  Wing  approves  ISs  unilaterally,  the 
Wing  chose  to  provide  some  of  the  LOEs  in  the  IS  in  order  to  document  the 
vendors’  concerns  publicly.  These  vendors  based  their  exceptions  on  cost, 
schedule,  or  performance  impacts  that  would  result  if — in  order  to  satisfy  newly- 
baselined  requirements — the  vendors  needed  to  increase  the  scope  of  their 
efforts  beyond  the  scope  defined  in  their  contracts.  Vendors  submit  these  letters 
because  they  need  to  justify  the  impact  of  changes.  The  GPS  Wing  can  respond 
to  these  letters  in  a  few  ways: 

•  The  GPS  Wing  can  authorize  a  Letter  of  Exception  to  stand  and 
document  it  in  the  IS  revision, 

•  The  GPS  Wing  can  reject  the  letter  and  pursue  contractual 
discussions  to  resolve  the  issue 

•  The  GPS  Wing  can  agree  to  provide  some  form  of  relief  to  the 
vendor  that  submits  the  letter. 

5.  GPS  Operating  Instructions  (Ols) 

There  are  two  draft  GPS  Wing  Ols  that  are  especially  relevant  to  this 
paper:  1)  the  draft  DOORS  OI  for  the  Dynamic  Object-Oriented  Requirements 
System  tool  used  by  the  government  and  vendors  for  the  GPS  program,  and  2) 
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the  incomplete  draft  Requirements  Engineering  01.  These  will  be  used  together 
in  order  to  guide  GPS  program  requirements  development,  management,  and 
verification. 

a.  DOORS  01 

The  Requirements  Branch  of  the  Systems  Engineering  Division 
maintains  the  DOORS  database,  capturing  requirements  and  allowing  this 
database  to  interact  with  those  DOORS  databases  of  the  vendors  who  also  use 
this  tool.  This  requirements  management  tool  is  widely-used  for  complex 
systems  like  the  GPS. 

Of  the  two  ways  in  which  a  development  program  can  manage 
requirements  in  DOORS,  the  GPS  program  uses  the  document-oriented 
approach  specified  in  the  draft  GPS  DOORS  01.  “GPS  has  adopted  a  document- 
based  approach  whereby  DOORS  modules  are  created  that  map  one-to-one  to 
the  program’s  documents”  (Chief  Engineer  GPS  Wing,  2006  draft).  The  draft  01 
also  directs  the  GPS  program  to  place  each  requirements  document  into  a 
separate  module.  All  modules  are  linked  in  a  hierarchy.  Objects  within  modules 
exist  for  each  section  heading  and  requirement  paragraph.  Related  modules  can 
be  grouped  into  DOORS  Projects,  such  as  for  a  segment  subsystem  of  the  GPS 
like  Modernized  User  Equipment  (MUE)  or  the  Block  IIP  Control  Segment. 

Because  some  requirements  are  classified,  the  draft  DOORS  01 
requires  that  an  up-to-date  duplicate  of  the  GPS  DOORS  database  reside  on  a 
stand-alone  computer  located  in  an  appropriately  secure  vault.  In  addition  to  the 
duplication  of  unclassified  GPS  requirements,  this  separate  database  includes  all 
classified  requirements  with  all  of  the  links  necessary  to  trace  up  to  higher-level 
requirements  or  assess  impacts  on  lower-level  requirements.  Access  to  this 
classified  database  and  the  classified  requirements  that  populate  it  is  limited  to 
those  who  have  the  appropriate  security  clearances  and  need-to-know. 

DOORS  attributes  help  to  clarify  and  categorize  requirements 
information  captured  in  objects.  The  draft  GPS  DOORS  01  Attachment  8 

recommends  that  each  program  adopt  the  definable  attributes  listed  in  Table  3. 
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•  Segment/Block 
Allocation 

•  Classification  level 

•  “Is”  Requirement  (T/F?) 

•  Performance  Area 

-  Accuracy,  Integrity,  etc. 

•  Technical  Performance 
Measure 

•  Requirement  ID 

-  Only  for  objects 
containing  a  reqt 

•  Requirements  POC 

•  Risk 

-  Low,  medium,  high 


•  Verification  Method 

-  Analysis,  test,  demo,  etc. 

•  Verification  POC 

•  Verification  Status 

-  Verified,  not  verified, 
passed,  failed 

•  Verification  Level 

-  System,  Segment 

•  Priority 

-  KPP,  non-KPP 

•  External  Reference 

-  Links  to  non-DOORS  doc. 

•  Rationale 

•  Comments 


Table  3.  Draft  GPS  Wing  DOORS  01  Recommended  Attributes 


In  addition  to  the  recommended  attributes,  assigned  attributes 
include  such  characteristics  as  the  object’s  creator,  creation  date,  and  last 
modification  date. 

For  example:  The  Requirement  ID  attribute  is  a  unique  identifier  for 
each  requirement.  The  Requirement  ID  attribute  remains  blank  for  non¬ 
requirement  objects,  and  a  sorting  feature  allows  for  a  document’s  (or  module’s) 
requirements  to  be  identified  and  presented  in  a  view  that  does  not  include  the 
other  objects. 
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As  requirements  change,  additional  attributes  can  help  to  track 
these  changes.  Changes  are  managed  using  the  GPS  Wing  requirements 
management  process  that  supports  the  Configuration  Control  Board  (CCB),  as 
shown  in  Figure  6  and  repeated  as  Figure  7  below.  The  CCB  can  only  control 
the  requirement  Verification  Method  and  Rationale  attributes.  Other  helpful 
attributes  include  the  ‘Was’  Requirement  attribute  to  identify  the  previous  wording 
of  a  requirement,  the  Proposed  Chanoe  attribute  to  identify  the  proposed 
wording.  Reason  For  Change  text  attribute,  and  the  Attribute/Link  Change 
Summary  attribute  to  summarize  changes  to  existing  requirement  attributes  as 
well  as  changes  to  the  links  to  other  requirements. 


•Technical  ’Reliability  ’Usability  Board  (ERB) 

•Performance  ’Securitv 


Figure  7.  GPS  Wing  Requirements  Management  Process  (After  Chief  Engineer 

Navstar  GPS  Joint  Program  Office,  2006a,  2006c). 
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The  01  also  requires  the  inclusion  of  the  Contract  Data 
Requirements  List  (CDRL)  items  in  DOORS.  The  CDRL  items  shall  include  the 
following  documents: 

•  The  System  Specification 

•  Segment  specifications 

•  Prime  item  development  specifications  that  trace  requirements  to 

their  respective  higher-level  specifications 

•  Interface  Control  Documents  (ICDs) 

•  Test  plans,  procedures  and  reports  (to  support  verification  of 

specification  requirements) 

Linking  is  a  powerful  DOORS  feature  that  facilitates  requirements 
analyses.  Traceability  and  impact  analyses  deal  with  external  links  that  focus  on 
requirements  relationships  up  to  parent  modules  (or  documents)  and  down  to 
child  modules.  The  01  requires  the  appropriate  steps  to  avoid  describing 
requirements  in  ways  that  complicate  the  ability  to  link  objects  that  contain 
requirements.  One  example  includes  the  requirement  for  DOORS  modules  to 
refrain  from  using  compound  requirements,  which  are  multiple  requirements 
attached  to  only  one  ‘shall’  statement.  Such  statements  should  be  broken  apart 
into  individual  ‘shall’  statements  and  then  re-linked  to  show  the  relationship 
between  them.  Another  example  is  to  use  DOORS  tables  in  which  each  cell 
contains  no  more  than  a  single  requirement.  When  it  is  not  possible  to  capture  a 
requirement  fully  in  a  single  ‘shall’  statement,  then  the  most  effective  practice  is 
to  establish  internal  links  (or  links  within  a  module)  to  explanative  objects  that  do 
not  contain  ‘shall’  statements.  These  objects  can  include  tables,  figures, 
equations  or  other  sources  of  information  that  help  to  describe  the  requirement 
fully.  Besides  traceability  and  impact  analyses,  other  analyses  related  to  links 
include  finding  orphan  requirements  objects  and  suspect  links.  Orphan 
requirements  do  not  have  parent  requirements  to  satisfy.  Suspect  links  can 
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emerge  when  the  contents  of  linked  objects  change,  and  as  a  result,  give  reason 
to  question  the  validity  of  the  links  to  those  objects. 

When  approved,  the  DOORS  01  will  require  that  DOORS  users  to 
refrain  from  using  generic  DOORS  links.  Instead,  GPS  DOORS  users  will  use 
requirements  links  to  connect  requirements  objects  in  different  modules. 
Similarly,  DOORS  users  will  also  use  test  and  verification  links  to  connect  test 
and  verification  data  to  higher-level  requirements  objects.  The  ability  to  define 
different  types  of  links  allows  DOORS  users  to  either  trace  through  requirements 
objects  or  find  test  and  verification  objects  more  quickly.  Finally,  special  links 
shall  be  defined  for  various  situations  as  needed,  including  the  linking  of 
proprietary  documents  and  also  for  linking  internal  GPS  Wing  documents  for 
Wing  use  only. 

In  addition  to  describing  the  utility  that  the  DOORS  database  can 
provide,  the  01  also  discusses  other  issues  that  are  mainly  DOORS  technical 
issues  rather  than  functions  it  performs.  These  issues  include  configuration 
management,  module  output  formats  and  reports,  technology  and  administrative 
support,  management,  and  user  training.  An  important  technical  issue  that 
affects  the  effectiveness  that  DOORS  can  have  for  a  program  involves  the  details 
of  how  to  prepare  documents  for  DOORS  importation.  Most  often  these  files  will 
be  Microsoft  Word  or  Excel  documents.  Often  these  documents  will  include 
figures  and  tables  that  must  be  handled  appropriately  in  order  to  facilitate  linking 
the  information  to  other  documents/modules.  For  example,  each  cell  within  a 
DOORS  table  for  a  given  module  can  be  linked  separately  to  other  modules. 

Lastly,  the  draft  DOORS  01  explains  the  roles  and  responsibilities 
for  the  following  program  personnel  and  organizations: 

•  DOORS  Management  Working  Group  (DMWG)  lead  by  the 

DOORS  Government  Project  Lead 

•  DOORS  Information  Technology  Support 

•  DOORS  Configuration  Manager  and  Training  Liaison  Manager 
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•  System  Engineering  Lead 

•  Program  Management  Lead 

•  DOORS  Module  Points  of  Contact,  and  the  Integrated  Product 

Teams  Coordinator  who  assigns  them 

•  Interface/Specification  Control  Contractors 

•  Program  Managers 

•  Configuration  Control  Board  Reviewers 

•  DOORS  users 

The  people  who  occupy  these  roles  and  participate  in  these  groups  are  charged 
with  ensuring  that  the  GPS  program  requirements  are  captured  fully,  that 
proposed  baseline  configuration  changes  are  tracked,  and  that  updates  are 
made  when  proposed  changes  are  approved.  The  government  also  works  with 
vendors  to  ensure  that  the  vendors’  DOORS  database  technology  and  practices 
remain  compatible  in  order  to  support  the  exchange  of  DOORS  information. 

While  the  DOORS  01  draft  was  available  for  review  on  March  23, 
2006,  the  GPS  Chief  Engineer  and  GPS  Wing  Commander  have  not 
implemented  this  document  as  policy  as  of  September  22,  2006.  While  the 
review  of  this  draft  continues,  the  GPS  program  also  faces  information 
technology  funding  challenges  that  will  limit  the  effectiveness  of  this  policy.  The 
GPS  Wing  currently  has  21  licenses  for  this  database  tool  to  share  among  even 
more  customers,  vendors,  and  other  stakeholders.  The  GPS  Wing  also  lacks 
funding  for  the  classified  workstation  to  handle  classified  requirements. 

b.  Requirements  Engineering  Oi 

At  the  time  of  publishing  for  this  thesis,  which  will  be  completed  by 
September  22,  2006,  the  Requirements  OI  existed  only  in  draft  form.  The  draft 
guidance  emphasizes  the  requirements  functions  and  associated  processes  for 


55 


carrying  out  these  functions  thoroughly.  The  three  requirements  engineering 
functions  are  listed  in  Table  4  below; 


•  Requirements 

•  Requirements 

•  Requirements 

Development 

Management 

Verification 

-  Identifying 

-  Establishing 

-  Verifying  products 

stakeholders 

resources 

-  Establishing  & 

&  their  needs 

-  Establishing 

maintaining 

-  Synthesizing 

requirements 

verification 

requirements 

providers 

environment 

-  Prioritizing  & 

-  Capturing 

-  Verifying 

categorizing 

information 

procedures 

requirements 

-  Managing 

-  Using  peer  review 

-  Validating 

change 

process 

requirements 

-  Creating 

-  Verifying  products 

-  Developing  a 

products 

-  Assisting  supplier 

high-level 

-  Managing 

verification 

baseline 

supplier 

-  Updating  JPO 

-  Documenting 

documentation 

System  Eng.  Plan 

requirements 

(SEP) 

Table  4.  Requirements  Engineering  Functions  listed  in  01. 


The  draft  DOORS  01  emphasizes  all  three  groups  of  functions 
described  in  the  Requirements  01.  While  much  work  remains  before  this  01  is 
complete  and  approved,  the  intent  appears  to  include  supporting  GPS  program 
needs  by  ensuring  well-defined  requirements  to  populate  the  DOORS  database. 

The  draft  Requirements  01  also  includes  a  checklist  for  systems 
engineers  to  use  when  writing  requirements.  The  checklist  includes  the  following 
questions  about  potential  requirements  statements: 
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Is  it  clear? 


•  Is  it  as  short  as  it  can  be? 

•  Does  it  apply  to  a  defined  type  of  user? 

•  Does  it  have  a  reasonable  priority? 

•  Is  it  verifiable? 

•  Is  it  a  single  requirement? 

•  Is  its  source  shown? 

•  Does  it  have  a  unique  identifier? 

•  Is  it  genuinely  a  user  requirement,  not  a  design  constraint? 

(Chief  Engineer  GPS  Wing,  2006  rough  draft) 

This  checklist  will  guide  engineers  and  program  managers  who  may  not 
remember  the  characteristics  of  a  good  requirement.  It  will  also  help  to 
encourage  a  consistent  level  of  requirement  statement  quality  across  GPS 
subsystem  acquisition  programs. 

C.  REQUIREMENTS  ENGINEERING  LITERATURE 

1 .  Software  Technology  Support  Center  (STSC) 

Jim  Van  Buren  and  David  A.  Cook  of  Draper  Laboratory  and  the  Software 
Technology  Support  Center  provide  a  history  of  requirements  engineering 
challenges  and  lessons  learned  in  their  paper  titled  Experiences  in  the  Adoption 
of  Requirements  Engineering  Technologies.  They  categorize  requirements 
engineering  into  the  following  five  categories: 

1 .  Elicitation  -  getting  customers  to  state  their  exact  requirements 

2.  Analysis  - 

a.  making  qualitative  judgments  about  system  requirements 
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b.  beginning  a  high-level  design  by  decomposing  the  system 
into  components  and  specifying  their  interfaces 

3.  Management  -  dealing  with  requirements  changes 

4.  Validation  and  Verification  - 

a.  Validation  -  building  the  right  system  (to  satisfy  customers) 

b.  Verification  -  building  the  system  right  (to  satisfy 
requirements) 

5.  Documentation  - 

a.  structuring  written  specifications 
or 

b.  choosing  and  structuring  a  requirements  database 

A  major  challenge  facing  many  programs  is  the  reality  that  many 
customers’  view  of  requirements  differs  from  that  of  developers.  Whereas 
developers  see  a  requirement  as  something  that  is  testable  and  may  be 
prioritized,  many  customers  think  of  requirements  in  terms  of  their  overall  needs. 
Skilled  requirements  elicitation  from  customers  helps  to  overcome  this  barrier  to 
defining  good  requirements  for  developers. 

There  are  many  well-established  approaches  to  requirements  analysis,  as 
well  as  tools  to  complement  these  approaches.  These  approaches  include 
requirements  modeling  techniques  such  as  traditional  structured  analysis  and 
objected-oriented  analysis.  (In  spite  of  its  name,  DOORS  is  not  an  object- 
oriented  analysis  tool.)  Even  with  proven  tools  and  approaches,  programs  run 
into  difficulties  when  tools  enforce  a  process  that  is  inconsistent  with  a 
development  program’s  process,  or  when  the  people  who  implement  the 
approach  and  tool  lack  sufficient  training  to  be  effective  with  them.  Van  Buren 
and  Cook  note  that  well-funded  programs  typically  overanalyze  requirements 
while  other  programs  tend  to  analyze  requirements  less  to  save  precious  funds. 


58 


The  requirements  management  portion  of  the  STSC  paper  addresses  how 
increased  requirement  volatility  also  increases  programmatic  risk.  While  volatility 
is  a  natural  result  when  building  a  useful  product,  it  is  desirable  to  control 
volatility  that  results  from  the  poor  elicitation  and  specification  of  requirements. 
Requirements  management  tools  can  help  track  and  measure  requirements 
volatility,  and  also  support  the  traceability  and  impact  analyses  up  and  down  a 
requirements  hierarchy.  These  tools  provide  information  that  should  not  only 
support  internal  programmatic  decision  making,  but  also  the  important  interaction 
with  customers  who  need  to  understand  the  impacts  of  requirements  changes. 

Developers  should  plan  requirements  validation  and  verification  as  early 
as  the  elicitation  phase.  Customers  and  users  will  not  accept  a  system  if  it 
doesn’t  meet  their  expectations,  so  developers  must  elicit  those  requirements 
that  are  necessary  to  ensure  that  the  right  system  is  built.  This  validation  is  one 
measure  of  requirements  quality.  The  other  measure  is  requirements 
verification.  If  requirements  are  not  verifiable,  it  will  be  impossible  to 
demonstrate  that  the  system  is  built  correctly.  The  customers  and  users  are 
essential  to  ensuring  system  validation  and  verification. 

Requirements  documentation  involves  specifying  “an  overall  description, 
external  interfaces,  functional  requirements,  performance  requirements,  design 
constraints,  and  quality  attributes”  (as  cited  in  Cook  &  Dupaix,  1999).  These  are 
explained  in  sources  like  withdrawn  DoD  standards  MIL-STD-2167A  and  MIL- 
STD-498,  as  well  as  industry  standards  like  ANSI/IEEE-STD-830-1993  and 
EIA/IEEE  12207.  Requirements  management  tools  can  also  support 
requirements  documentation  needs. 

2.  DOORS  Database  Documentation 

The  Dynamic  Object-Oriented  Requirements  System  (DOORS)  database 
is  a  Telelogic  product  that  is  widely  used  for  managing  requirements  of  complex 
development  programs  in  industries  like  aerospace  and  defense.  Using  modules 
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and  objects  within  DOORS,  the  GPS  program  uses  this  database  product  to 
store  and  track  program  requirements.  Among  this  tool’s  strengths  are  the 
traceability  and  attributes  features. 

Modules  are  files  that  are  used  to  capture  requirements  about  an  area  of 
concern.  For  example,  the  GPS  program  uses  separate  files  for  each  system 
specification  and  segment  specification.  All  lower-level  specifications  are  also 
separate  modules  that  are  linked  to  higher-level  modules,  as  appropriate,  in 
order  to  enable  requirements  traceability  or  impacts  analyses.  Objects  in 
DOORS  are  distinguishable  entities  within  modules,  and  these  have  unique 
DOORS  identification  numbers  assigned  to  them  automatically. 

As  Figure  8  below  shows,  if  all  GPS  III  requirements  were  loaded  into 
DOORS  and  linked  properly,  it  would  be  possible  to  look  at  the  GPS  III  System 
Specification  to  see  which  requirements  statements  at  different  levels  are  related. 
In  this  notional  example,  traceability  analyses  help  to  ensure  that  the 
implementation  of  lower-level  requirements  results  in  the  required  subsystem  or 
overall  system  performance.  Similarly,  impact  analyses  allow  one  to  see  how 
changes  made  to  objects  in  higher-level  modules  will  affect  objects  in  lower-level 
modules.  The  person  conducting  the  traceability  and  impact  analyses  can  also 
choose  the  depth,  or  number  of  levels,  that  are  of  interest  in  either  type  of 
analysis.  For  example,  one  may  only  wish  to  see  immediate  requirements  traces 
or  impacts  that  go  no  further  than  one  module  up  or  down,  respectively.  With 
computer  mouse  clicks,  both  of  these  features  allow  the  DOORS  user  to  move 
from  object  to  object  across  modules  in  order  to  access  related  requirements. 
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GPS  III  CDD  Module 


Object  1 

Object  2 

Object  3 

Object  4 

Object  5 

Object  6 

In-Link  traceability 


Upward  (traceability) 
and  downward 
(impact)  analyses 
are  possible  for 
notional  “Object  6”  in 
the  GPS  III  System 
Specification  Module 


Out-Link  impacts 


GPS  III  System  Specification  Module 

Object  1 

Object  2 

Object  3 

Object  4 

Object  5 

Object  6 

ik 

GPS  III  Space  Segment 


Specification  Module 


Object  1 


Object  2 


Object  3 

Object  4 

Object  5 

GPS  II 

Control  Segment 

Specification  Module 

Object  1 

Object  2 

Object  3 

1 

r 

Dbject  4 

Object  5 

Object  6 

Figure  8.  Notional  GPS  III  Example  of  DOORS  Traceability  and  Impacts. 

In  addition  to  linking  requirements,  it  is  easy  to  include  other  important 
information  in  DOORS  to  support  system  acquisition  activities.  In  particular, 
modules  and  objects  can  capture  design  and  test  information.  When  linked 
properly,  it  is  possible  to  trace  test  events  to  the  design  features  to  be  verified, 
and  continue  to  the  requirements  that  the  design  features  are  to  satisfy. 

When  creating  links,  it  is  possible  to  define  different  types  of  link 
characteristics  in  link  modules: 

•  Many-to-many:  each  object  can  have  many  in-links  and  out-links 
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•  Many-to-one:  each  object  can  have  many  in-links,  but  only  one  out- 

link 

•  One-to-many:  each  object  can  have  only  one  in-link,  but  many  out- 

links 

•  One-to-one:  each  object  can  have  only  one  in-link  and  one  out-link 

Link  module  subdivisions  called  linksets  include  information  about  the 
links  from  one  module  to  another  or  within  modules.  When  dealing  with  only  two 
modules,  four  linksets  define  links  from  Module  1  to  Module  2,  Module  2  to 
Module  1,  Module  1  to  Module  1  (for  links  between  objects  in  Module  1),  and 
Module  2  to  Module  2.  The  direction  of  links  is  important,  as  shown  in  Figure  8. 
While  there  is  a  default  DOORS  link  module,  it  is  also  possible  to  define  different 
types  of  link  modules  for  different  purposes  in  order  to  improve  organization, 
facilitate  analysis,  or  limit  user  access. 

DOORS  objects  have  the  ability  to  be  described  by  up  to  32  attributes. 
Attributes  are  characteristics  that  some  requirements  will  likely  share,  and  some 
of  these  are  determined  by  the  DOORS  database  while  others  are  chosen  by  the 
system  engineer  who  manages  DOORS.  The  modules  that  include  objects  can 
have  an  unlimited  number  of  attributes  to  pass  on  to  the  objects  within  the 
modules. 

Tables  5  and  6  show  the  types  of  attributes  and  attribute  types  that  one 
can  expect  to  find  in  DOORS.  While  it  is  possible  to  edit  some  of  the  system 
attributes  for  either  modules  or  objects  (shown  in  italics),  others  are  read-only.  In 
addition  to  system  attributes  and  DOORS-preset  attribute  types,  there  are  also 
user-defined  attributes  and  attribute  types.  The  information  contained  within 
Tables  5  and  6  comes  from  the  Help  menu  provided  in  Telelogic  AB’s  DOORS 
7.1  database.  This  Help  menu  serves  as  a  comprehensive  DOORS  7.1  users 
manual. 
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Svstem  Attributes  for 

Svstem  Attributes  for 

Modules 

Obiects 

• 

Created  By 

•  Absolute  number 

• 

Created  On 

•  Created  By 

• 

Description 

•  Created  On 

• 

Last  Modified  By 

•  Created  Thru 

• 

Last  Modified  On 

•  Last  Modified  By 

• 

Mapping  (one-to-one  or 

•  Last  Modified  On 

many-to-many;  only  for 

•  Object  Heading 

link  modules) 

•  Object  Short  Text 

• 

Name 

•  Object  Text 

• 

Prefix 

•  (advanced  system 

attributes  that  show 

status  information) 

Table  5.  System  Attributes  for  Modules  and  Objects. 
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Base  Attribute  Types 

•  Text 

•  String 

•  Integer 

•  Real 

•  Date 

•  Enumeration 

-  this  allows  attribute  to 
take  on  one  of  a 
predefined  set  of  values 

•  Username 


User-Created  Attributes 

•  Kilogram 

-  Base  type  Integer 

•  Dollar 

-  Base  type  Integer 

•  Percentage 

-  Base  type  Integer 

•  Deviation 

-  Base  type  Real 

•  Priority 

-  Base  type  Enumeration 

•  Rationale 

-  Base  type  String 


Table  6.  Attribute  Types — Base  &  Some  Possible  User-Created. 

DOORS  allows  the  ability  to  take  user-defined  attributes  from  other 
modules  and  import  them  into  the  module  a  user  is  working  on.  In  the  case  of 
GPS,  it  could  be  helpful  to  use  existing  module  and  object  attributes  defined  for 
an  existing  block  of  space  vehicles  to  help  describe  the  requirements  for  the 
corresponding  DOORS  objects  and  modules  used  for  future  block  acquisition 
programs. 

D.  CHAPTER  SUMMARY 

This  chapter  reveals  the  various  requirements  engineering  literature  that  is 
available  to  the  GPS  program  and  to  the  broader  systems  development 
community.  While  it  is  important  not  only  to  define  a  development  program’s 
system  requirements  clearly,  it  is  also  important  to  organize  and  manage  these 
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requirements  effectively  so  that  program  managers  and  systems  engineers  can 
support  the  design  and  verification  of  systems.  It  is  also  important  to  implement 
methodologies — a  combination  of  models,  tools,  and  techniques — that  are 
aligned  with  these  requirements  engineering  activities  rather  than  disrupt  them. 
The  DOORS  database  is  a  tool  that  is  aligned  with  the  GPS  Wing’s  requirements 
practices.  The  database  attributes,  linking,  and  traceability  features  allow  users 
to  store  and  organize  information  in  a  way  that  supports  analysis  and  decision¬ 
making.  The  next  chapter  addresses  the  implementation  of  these  ways  to 
improve  how  the  GPS  program  handles  all  three  areas  of  its  requirements 
engineering  activities:  requirements  development,  requirements  management, 
and  requirements  verification. 
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IV.  RESEARCH  ANALYSIS  AND  RECOMMENDED 
APPLICATION  OF  STUDY 

A.  INTRODUCTION 

The  literature  reviewed  and  the  interviews  conducted  with  GPS  Wing 
personnel  serve  as  the  foundation  for  this  chapter.  Recommendations  span  the 
requirements  engineering  activities  that  include  how  the  GPS  program  elicits, 
stores,  manages,  evaluates,  and  changes  its  program  technical  baseline.  This 
chapter  attempts  to  answer  as  completely  as  possible  the  research  questions 
posed  in  Chapter  I.  Many  of  these  conclusions  demonstrate  that  effective 
solutions  do  not  necessarily  require  new  material  solutions  like  a  new  database. 
Some  changes  in  institutionalized  practices  alone  offer  new  possibilities  for 
improving  requirements  engineering  and  decision-making  agility.  The  Dynamic 
Object-Oriented  Requirements  System  (DOORS)  is  a  capable  requirements 
management  tool  in  use  by  the  GPS  Wing.  While  any  tool  has  room  for 
improvement,  DOORS  is  adequate  for  the  manner  in  which  it  is  used,  has  been 
successful  in  the  past,  and  has  a  tremendous  amount  of  untapped  potential  to 
support  the  GPS  program  requirements  engineering  needs. 

B.  CHANGING  TO  A  REQUIREMENTS-CENTRIC  APPROACH 

As  shown  in  Figure  5  and  repeated  as  Figure  9  below,  the  GPS  Wing 
elicits  its  requirements  from  the  Headquarters  of  the  U.S.  Air  Force  (HQ  USAF), 
Air  Force  Space  Command  (AFSPC),  U.S.  Strategic  Command 
(USSTRATCOM),  and  the  Interagency  Forum  for  Operational  Requirements 
(IFOR).  These  organizations  provide  their  inputs  by  means  of  documents  that 
exist  to  serve  a  broad  audience  of  systems  engineers,  program  managers, 
customers,  and  users.  The  format  of  these  documents  makes  them  useful  to  all, 
but  it  is  not  a  format  that  is  most  practical  for  the  engineers  and  managers  who 
access  the  requirements  and  study  them  meticulously.  The  chapter,  paragraph 
and  sentence  structure  may  appeal  the  most  to  the  customers  because  it  is 
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familiar,  but  this  structure  makes  it  more  difficult  for  engineers  and  program 
mangers  to  organize  their  requirements  in  order  to  ensure  they  deliver  the 
product  that  the  customer  wants.  With  a  requirements-centric  use  of  the  DOORS 
database  tool  for  the  GPS  program,  the  GPS  Wing  could  streamline  its 
requirements  engineering  activities  and  reap  benefits  that  go  from  development 
activities  through  design  verification  and  system  deployment.  However,  the  GPS 
Wing  has  no  plans  to  demonstrate  and  take  advantage  of  this  model.  The  draft 
DOORS  01  shows  that  the  GPS  Wing  will  follow  the  document-centric  model, 
which  follows  the  lead  of  AFSPC  after  it  refused  to  provide  a  requirements- 
centric  ODD  (Campbell,  J.,  personal  communication,  July  25,  2006). 


DoS 

Bilaterals* 
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ITU  {United_ 
Nations) 
Non-DoD 
Signal  Design 
Sources, 
Constraints 


Customers 

HQ  USAF 
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Customer 

USSTRATCOW 

Customer 

AFSPC/DRN 

User  Communities 
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CONORS 


SORD 


ORD 


Systems  Engineering 


SARPs 


User  Equipment 
Test  &  Inteqration 


Block  1 
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Block  3 

System 

System 
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Specs 

Specs 
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Specs,  Interface  definitions,  &  commitments  ICDs 
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Global  Positioning  System 


'Agreements  with  foreign 
governments,  such  as 
Japan  (Quazi-Zenith 
Satellite  System)  and  the 
European  Union  (Galileo) 


Figure  9.  GPS  Requirements  Documents  and  Requirements  Sources  (After 

Alexander,  2006;  and  After  Chief  Engineer  Navstar  GPS  Joint  Program 

Office,  2006c) 
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The  DOORS  database  stores  specification  information  in  a  manner  that 
mimics  each  document’s  structure.  Users  treat  it  as  a  document  repository.  For 
these  documents,  each  of  which  is  a  DOORS  module,  the  objects  are  arranged 
in  the  order  they  appear  as  headings  or  paragraphs  in  the  source  document.  As 
used  by  most  GPS  Wing  account  holders,  DOORS  offers  no  advantage  over 
using  the  source  requirements  documents  themselves.  The  lack  of  links 
between  requirement  objects  and  the  limited  use  of  user-defined  attributes 
prevents  anybody  from  conducting  queries  that  would  otherwise  help  to  trace, 
filter,  or  sort  through  requirements  objects  of  interest.  Thus,  these  users  are  not 
exploiting  the  most  powerful  features  that  DOORS  offers. 

Current  users  have  exposed  another  flaw  with  the  document-centric 
approach  that  prevents  them  from  exploiting  the  capabilities  of  DOORS. 
Because  they  see  a  format  for  information  that  mimics  the  source  documents, 
users  tend  to  expect  to  have  word  processing  and  spreadsheet  functionality  that 
allows  editing.  For  example,  Microsoft  Word  and  Excel  source  documents  must 
be  updated  first  before  uploading  the  entire  blocks  of  text  or  entire  tables  as 
DOORS  objects  to  replace  the  existing  objects.  The  need  to  perform  this  kind  of 
procedure  causes  some  to  question  the  value  of  the  DOORS  tool,  but  this  user 
expectation  is  evidence  of  a  DOORS  tool  education  problem  and  an 
implementation  weakness  that  results  from  the  document-centric  approach 
specified  in  the  draft  GPS  DOORS  01.  These  users  do  not  appreciate  the 
capabilities  of  databases  in  general. 

The  requirements  engineering  goal  for  the  GPS  program  should  be  to  do 
away  with  the  various  requirements  documents  it  tracks,  and  instead  focus  on 
the  structure  of  the  system’s  requirements.  Much  of  the  information  contained  in 
these  documents  is  background  information  that  does  not  describe  requirements 
that  the  program  must  satisfy  for  its  customers.  This  information  could  go  into 
documents  that  provide  background  information,  but  it  should  not  get  mixed  with 
new  requirements  because  of  the  problems  that  can  and  do  result  from  the 
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ambiguity  regarding  whether  a  statement  is  a  requirement  or  not.  Requirements 
are  not  all  listed  together  in  the  current  documents. 

Because  it  is  in  wide  use  by  vendors  and  the  GPS  Wing,  the  DOORS 
database  is  available  and  able  to  support  building  requirements  hierarchies  that 
can  take  over  the  requirements  roles  played  by  capability  and  specification 
documents.  While  the  DOORS  tool  can  support  other  uses,  the  definition  of 
DOORS  requirements  links  can  eliminate  the  problem  that  would  arise  by  using 
the  default  DOORS  links  to  connect  requirements  objects  with  other  objects  such 
as  Test  and  Verification  objects.  While  these  objects  can  be  linked  to 
requirements  objects,  it  is  useful  to  be  able  to  filter  out  these  objects  if  one  only 
wishes  to  see  requirements  objects  that  are  linked  with  program-defined 
requirements  links.  The  DOORS  files  that  the  GPS  Wing  and  its  vendors  could 
share  would  use  the  structure  shown  in  Figure  10; 
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DOORS  Super-Tier  Project  Folder 


Figure  10.  DOORS  Database  Structure 

This  structure  applies  to  the  document-centric  structure  in  use  as  well  as 
the  requirements-centric  structure  that  the  GPS  program  could  use.  One 
advantage  that  is  not  implemented  for  the  various  GPS  subsystem  development 
programs  is  the  linking  feature  that  supports  traceability.  While  the  DOORS  OI 
will  mandate  that  programs  not  use  the  default  DOORS  links,  this  will  not  be  an 
issue  for  most  programs  because  they  have  not  linked  their  requirements  objects 
yet.  There  are  links  defined  between  the  Block  III  Space  and  Control  ODD  and 
System  Specification  that  reside  in  their  own  DOORS  project  folder.  This  project 
folder  will  eventually  have  objects  that  are  linked  to  the  separate  DOORS  project 
folders  for  the  Block  III  Space  Segment  and  Block  III  Control  Segment  programs 
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when  those  get  underway.  In  general,  programs  that  are  represented  by  project 
folders  in  Figure  10  could  link  their  requirements  objects  across  modules  and 
other  project  folders  that  reside  in  the  same  super-tier  project  folder. 


1.  Requirements  Development 

AFSPC  provided  the  GPS  Wing  the  June  3,  2005  CDD  instead  of 
agreeing  to  provide  requirements  in  a  manner  that  supports  a  requirements- 
centric  use  of  the  DOORS  database.  In  doing  so,  the  customer  made  a  decision 
that  affects  how  other  customers  and  stakeholders  communicate  their 
requirements  and  needs  to  the  GPS  Wing.  The  long-term  impact  will  include  a 
greater  amount  of  work  for  all  customers. 

By  employing  a  requirements-centric  approach,  the  GPS  program  could 
have  taken  advantage  of  existing  requirements  in  order  to  limit  the  amount  of 
requirements  development  necessary  for  new  deliverables.  Rather  than  reinvent 
legacy  requirements,  the  GPS  Wing  could  reuse  these  legacy  requirements  and 
focus  on  developing  new  requirements  only.  As  an  example,  consider  the  U.S. 
civil  aviation  community’s  interest  in  GPS  service  continuity.  While  also 
interested  in  new  civil  signals  and  the  capabilities  that  would  come  along  with 
them,  this  stakeholder  group  provided  detailed  backwards  compatibility 
requirements  through  the  IFOR  to  emphasize  the  civil  priority  for  the  GPS  to 
continue  providing  existing  services  at  equal  or  greater  levels  of  service  quality 
(Cryderman,  J.,  personal  communication,  July  24,  2006).  These  levels  of  service 
quality  are  measured  in  such  general  terms  as  availability,  integrity,  and 
accuracy.  These  types  of  quality  are  enumeration  choices  for  the  Performance 
Area  recommended  attribute  type  in  the  draft  DOORS  01  (see  Table  3).  The 
development  of  these  “backwards  compatibility”  requirements  from  this  GPS 
stakeholder  group  would  be  much  simpler  and  prone  to  fewer  omissions  and 
errors  if  the  GPS  program  reused  legacy  requirements  objects  rather  than  rewrite 
legacy  requirements  into  new  capability  or  specification  documents.  This  type  of 
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approach  would  facilitate  efficient  documentation  of  requirements  across 
generations  by  ensuring  that  legacy  requirements  that  are  still  valid  continue  to 
drive  development. 

For  a  new  subsystem  development  program,  legacy  requirements  could 
be  assigned  a  newly  defined  effectivity  attribute  choice  among  the  already 
existing  enumeration  choices.  The  new  effectivity  attribute  for  legacy 
requirements  would  link  these  requirements  to  new  subsystem  development 
programs.  Figure  11  shows  a  notional  example  of  this  requirements  reuse 
practice  by  including  two  Block  IIF  Control  Segment  requirements  among  the 
Block  III  Control  Segment  requirements.  The  current  document-centric  practice 
would  have  many  requirements  objects  duplicated  unnecessarily  in  different 
DOORS  projects  folders  within  a  super-tier  project  instead  of  limiting  new 
requirements  objects  to  those  for  new  requirements  only.  For  this  suggestion  to 
work,  legacy  requirements  would  need  to  be  stored  in  a  format  that  makes  them 
reusable.  In  other  words,  the  program  would  need  to  define  and  use  effectivity 
attributes  for  the  legacy  requirements  that  are  stored  as  DOORS  objects — 
something  not  done  for  most  DOORS  objects  in  the  GPS  program. 
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Link  up  to  the  Block  IIP 
System  Specification 
Module 


Block  IIP  Control  Segment 
Specification  Module 
with  Unique  Objects 
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Links  to  the  Modules 
at  the  next  level  down 


Link  up  to  the  Block  III 
System  Specification 
Module 


Block  III  Control  Segment 
Specification  Module 
with  Unique  Objects 
(Requirements) 


Object  1 

Object  4 

Object  2 

Object  5 

Object  3 

Object  6 

Links  to  the  Modules 
at  the  next  level  down 


Figure  1 1 .  Example  of  Existing  Requirement  Reuse  in  the  next  Block  Upgrade 


Beyond  GPS,  this  cross-generation  benefit  would  apply  not  only  to  legacy 
systems  that  are  continuously  upgraded,  but  also  to  development  efforts  for  new 
system  requirements  when  the  new  system  will  replace  the  old  system 
completely.  In  the  DoD  acquisition  structure  and  while  using  a  requirements- 
centric  approach,  it  could  be  possible  to  export  requirements  database 
information  from  one  program  office  (or  Wing)  to  the  database  of  another.  The 
requirements  will  change,  but  the  objects  could  be  rewritten  while  preserving  the 
types  of  requirements  the  new  program  office  must  address.  However,  the  new 
program’s  decision  makers  would  need  to  weigh  the  costs  versus  benefits  to 
overcoming  technical  challenges  if  it  becomes  necessary  to  transfer  the 
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information  from  one  requirements  management  database  to  a  dissimilar  tool.  If 
customers  like  Air  Combat  Command  and  Air  Force  Space  Command  provided 
tool-specific  requirements-centric  inputs  and  enforced  the  use  of  that  single  tool 
by  its  acquisition  Wings,  then  tool  incompatibility  would  not  be  a  big  issue. 

2.  Requirements  Management  and  Documentation 

Requirements  management  deals  with  the  decisions  regarding 
requirements  changes.  Requirements  documentation  deals  with  how 
requirements  are  stored,  handled,  and  presented  in  reports.  Effective 
documentation  of  baselined  requirements  helps  decision  makers  access  the 
requirements  information  they  need  in  order  to  support  efforts  to  change 
requirements.  Requirements  documentation  also  addresses  linking  requirements 
to  organize  them  better  and  support  analyses,  tracking  changing  requirements 
attributes,  and  generating  formal  reports.  The  goal  for  performing  these 
requirements  management  and  documentation  functions  well  is  to  improve  the 
speed,  quality,  and  confidence  of  engineering  and  program  management 
decisions. 

Because  the  GPS  program  works  with  vendors  that  also  use  DOORS,  one 
of  the  most  important  requirements  documentation  and  management  issues 
involves  the  transfer  of  requirements  information  between  the  GPS  Wing  and  its 
vendors.  Currently,  this  transfer  occurs  with  the  exchange  of  requirements 
documents.  The  government  provides  high-level  requirements  documents  that 
are  compliance  documents  on  a  contract,  and  the  vendors  share  the  lower-level 
specifications  they  produce  in  order  to  satisfy  these  higher-level  requirements. 
The  GPS  Wing  technical  experts,  who  consist  primarily  of  FFRDC  personnel  and 
SETA  contractors,  review  the  vendor-produced  documentation  in  order  to  ensure 
that  the  requirements  contained  within  these  documents  are  complete  and 
accurate  enough  to  address  requirements  in  higher-level  specifications.  Linking 
and  reviewing  a  hierarchy  of  requirements  stored  in  DOORS  could  accomplish 
the  same  goal  more  efficiently  and  with  greater  assurance.  Instead  of 
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transferring  documents,  vendors  could  provide  their  DOORS  objects,  modules  or 
project  folders  for  lower-level  requirements  instead.  Vendors  have  already 
exchanged  DOORS  extracts  with  the  GPS  Wing,  but  neither  party  relies  on  this 
method  for  the  purpose  of  exchanging  requirements  information  that  will  undergo 
review. 

Creating  a  hierarchy  of  requirements  in  DOORS  with  clear  parent-child 
relationships  would  ultimately  support  efforts  to  verify  that  a  produced  subsystem 
satisfies  its  requirements.  This  requirements  development  method  would  result 
in  a  database  for  managing  requirements  and  eventually  supporting  design 
verification  activities.  The  GPS  Wing  would  be  the  only  organization  with  copies 
of  all  DOORS  project  folders  within  its  super-tier  project  folder.  As  indicated  in 
Figure  12,  the  GPS  Wing  would  exchange  copies  of  DOORS  project  folders  with 
the  appropriate  vendors.  Doing  so  ensures  a  common  baseline  understanding  of 
each  program’s  requirements  between  the  GPS  Wing  and  the  appropriate 
vendors.  Vendors  would  begin  by  using  their  copies  of  the  government-created 
DOORS  database  information  to  grow  requirements  trees  to  greater  depths. 
Within  the  project  folders  shown  in  Figure  12,  changes  to  the  modules  for  the 
government-defined  system  and  segment  specifications  would  require 
government  coordination. 
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Figure  12.  Synchronizing  GPS  Wing  and  Vendors’  DOORS  Information 


If  there  is  a  change  in  practice  to  a  requirements-centric  approach  for  the 
GPS  program,  some  stakeholders  will  still  prefer  to  have  access  to  document- 
style  descriptions  of  requirements.  For  these  people,  the  DOORS  database  can 
support  the  production  of  reports  that  emulate  this  style,  and  these  stakeholders 
could  produce  reports  themselves  by  establishing  accounts  and  learning  how  to 
use  the  tool.  Flowever,  much  of  the  background  information  found  in  many  such 
documents  would  have  to  come  from  sources  other  than  the  requirements 
objects.  This  information  could  reside  in  non-requirements  objects  in  DOORS  or 
in  documents  that  exist  to  preserve  background  information. 
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The  system  Configuration  Control  Board  (CCB)  personnel  in  the  Systems 
Engineering  Division’s  Requirements  Branch  have  both  read  and  write  access, 
but  most  requirements  stakeholders  should  have  read-only  access  to  the  GPS 
DOORS  database.  Organization  of  GPS  program  requirements  in  a 
requirements-centric  fashion  and  granting  broad  read-only  access  would  benefit 
engineers  by  allowing  them  to  study  requirements  in  a  format  that  supports  their 
requirements  organization  and  traceability  needs  best,  and  support  other 
stakeholders  without  causing  a  significant  long-term  inconvenience.  The  short¬ 
term  inconveniences  would  include  establishing  accounts  and  receiving  the 
training  necessary  to  navigate  the  database,  trace  requirements,  and  produce 
reports.  Requirements  stakeholders  should  develop  a  familiarity  with  DOORS 
that  matches  the  familiarity  that  many  have  with  word  processing  and  electronic 
mail  applications.  If  the  goal  is  to  improve  the  management  of  GPS 
requirements,  then  the  solution  will  also  need  to  include  the  enforcement  of 
consistent  practices  that  support  this  goal. 


a.  Requirements  Defined,  But  Not  Needed 

Current  requirements  are  not  the  only  ones  worth  managing.  It 
would  be  useful  to  track  requirements  that  no  longer  apply  to  any  development 
program  because  they  have  been  satisfied  or  because  of  a  reduction  in  technical 
scope  for  existing  programs.  The  draft  DOORS  01  identifies  the  Was’ 
Requirement  attribute  as  a  way  to  track  these  requirements.  If  the  requirement 
becomes  valid  again  as  a  result  of  new  activities  for  a  new  program,  a  program 
manager  or  systems  engineer  could  recommend  the  assignment  of  the  new 
effectivity  attribute  that  indicates  the  new  program  to  which  the  ‘Was’ 
Requirement  s\nou\6  belong. 

There  are  other  possible  ‘Was’  Requirements  that  may  never 
become  requirements  for  the  GPS  Wing  and  its  vendors  to  satisfy.  Even  so,  it  is 
still  useful  from  a  requirements  management  perspective  to  retain  these 
requirements  in  the  database  for  reference  purposes.  Someone  involved  in  the 
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GPS  program  may  not  know  that  a  requirement  is  no  longer  valid  or  understand 
why.  Requirement  history  is  important  for  understanding  why  some  requirements 
fade  and  others  remain  valid  from  one  generation  to  the  next.  This 
understanding  reduces  the  amount  of  time  wasted  when  reevaluating  a 
requirement. 


b.  Requirements  Needed,  But  Not  Defined 

There  are  cases  when  requirements  development  activities  for  a 
capability  do  not  account  for  all  requirements  that  need  to  be  satisfied  in  order  to 
fully  implement  the  capability. 

For  example,  the  GPS  Wing  Space  Segment  Group  has  already 
supported  the  production  and  launch  of  Block  HR  satellites  that  can  broadcast  the 
M-Code  ranging  signal.  However,  because  of  a  reduction  in  the  scope  of  the 
Control  Segment’s  Block  I  IF  contract,  the  Control  Segment  Group  does  not  have 
a  requirement  for  monitoring  such  a  signal  or  for  providing  an  appropriate 
Navigation  message  to  combine  with  it.  This  example  shows  how  requirements 
development  is  complete  for  one  segment,  but  not  for  the  entire  system. 

As  a  practice  to  be  added  to  the  GPS  Requirements  01,  the  GPS 
Wing  should  specify  the  development  and  management  of  system-level  and  all 
segment-level  requirements  necessary  to  implement  a  capability.  The  M-Code 
monitoring  capability  is  now  planned  for  the  first  increment  of  the  Block  III  Control 
Segment. 

A  special  case  of  undocumented  GPS  Control  Segment 
requirements  could  have  been  solved  easily  by  using  DOORS  with  a 
requirements-centric  approach.  The  Control  Segment’s  offline  tools  were 
developed  without  GPS  Wing  support  in  order  to  support  the  existing  needs  of 
the  Control  Segment  operators.  Before  the  GPS  III  Space  and  Control  CDD 
documented  these  requirements,  engineers  could  have  created  a  separate 
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module  for  these  requirements  objects  and  linked  them  as  needed  without  having 
a  requirements  document  to  rely  on. 

c.  Supporting  Analyses  for  Baseline  Changes 

After  requirements  definition  and  baseline  approval,  analysis 
activities  continue  throughout  the  system’s  lifecycle.  A  requirements-centric 
approach  to  requirements  management  and  documentation  would  support  these 
analysis  activities.  In  a  manner  similar  to  other  program  organizations,  the  GPS 
Wing  may  decide  or  be  required  to  conduct  What-lf  6n\\s  to  determine  the  effects 
of  possible  changes  to  requirements.  The  drills  may  result  from  internal 
questions  that  arise  due  to  technical  development  challenges,  disputes  between 
vendors  developing  opposing  sides  of  subsystems  that  will  share  an  interface,  or 
because  a  customer  like  HQ  USAF  would  like  to  study  alternative  requirements. 
During  these  drills,  the  subject  matter  experts  conduct  the  technical  analysis 
necessary  to  assess  the  impacts  of  requirements  changes  on  subsystem 
programs.  Currently,  these  individuals  rely  solely  on  their  expertise  and  diligence 
because  they  do  not  have  a  requirements-centric  implementation  of  DOORS  to 
support  their  analysis.  The  DOORS  standard  view  offers  a  sequential  list  of  a 
module’s  objects — headings,  paragraphs,  tables,  and  figures  extracted  from  each 
requirements  document  in  the  order  that  they  appear  in  a  document.  A 
traceability  view  would  show  how  child  objects  are  linked  to  parent  objects.  In 
short,  additional  analysis  develops  requirements  further.  The  ability  to  trace  up 
or  assess  impacts  down  a  properly  linked  requirements  hierarchy  would  support 
these  efforts.  However,  there  are  no  links  established  to  support  requirements 
traceability  analyses. 

The  GPS  Wing  would  benefit  from  DOORS  use  practices  that 
support  rapid  identification  of  all  related  requirements  and  allow  users  to  then 
proceed  with  their  analysis.  A  requirements-centric  approach  in  which 
hierarchies  of  requirements  are  linked  properly  would  improve  analysts’  and 
decision  makers’  collective  confidence  that  the  conclusions  take  into  account  all 
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relevant  requirements.  The  customer  would  benefit  by  receiving  rapid  and  well- 
researched  answers  with  which  to  make  decisions  about  changing  requirements. 
In  addition  to  technical  confidence,  program  decision  makers  and  customers 
would  also  benefit  from  the  stronger  confidence  in  cost  and  schedule  analyses 
that  accompany  technical  analyses.  These  decisions  are  made  using  the  system 
Configuration  Control  Board  (CCB)  process  that  impact  the  working  groups  and 
organizations  named  in  Figures  6  and  7.  Organizations  include  the  appropriate 
vendors  as  well  as  the  various  GPS  Wing  organizations  such  as  the  Systems 
Engineering  Division,  affected  Program  Managers’  Groups,  the  Program  Control 
Division,  and  the  Contracts  Division.  Working  groups  that  provide 
recommendations  to  the  CCB  include  the  GPS  Wing  Engineering  Review  Board 
(ERB)  and  Interface  Control  Working  Groups  (ICWGs).  Changes  approved  via 
this  CCB  process  require  subsequent  updates  to  relevant  documentation  and 
DOORS  objects  that  mirror  this  documentation. 

3.  Requirements  Validation,  Verification  and  Testing 

Requirements  validation  and  verification  are  other  forms  of  analysis  that 
would  benefit  from  a  requirements-centric  approach  to  requirements  engineering. 
If  successful,  validation  and  verification  events  bring  closure  to  open 
requirements.  Clear  traceability  of  lower-level  requirements  up  to  System-level 
requirements  supports  final  validation,  verification,  and  testing. 

a.  Validation 

Customers  with  government  DOORS  accounts  would  have  access 
to  the  information  needed  to  validate  system-level,  segment-level  or  even  lower- 
level  requirements.  Invalidating  requirements  derived  from  the  CDD  or  system- 
level  requirements  will  reveal  misunderstandings  about  a  customer’s  intent.  If 
interested  in  greater  levels  of  detail,  customers  would  have  an  opportunity  to  see 
how  their  requirements  develop  and  understand  issues  that  arise.  Access  to 
DOORS  should  encourage  customers  to  interact  more  with  the  GPS  Wing  to 
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resolve  issues.  Because  customers  often  do  not  appreciate  the  challenges  that 
their  requirements  can  cause  or  the  consequences  of  those  challenges, 
customers  may  be  willing  to  modify  or  relent  on  requirements  that  are  not  as 
important  as  once  thought.  As  a  result,  this  additional  insight  would  offer 
opportunities  for  customers  to  contribute  to  solutions  that  save  cost  and  schedule 
for  more  important  capabilities. 

b.  Verification 

Establishing  and  using  a  hierarchy  with  clear  and  accurate 
relationships  would  eliminate  the  ambiguity  that  exists  presently  and  fuels 
conflicts  between  vendors  and  GPS  Wing  personnel  during  verification  events. 
DOORS  can  support  the  development  and  management  of  requirements  in  this 
way  to  make  requirement  verification  progress  easier  to  assess. 

For  example:  The  Block  IIF  System  Specification,  Block  IIF  Space 
Segment  Specification,  and  the  Block  IIF  Control  Segment  Specification  all  have 
requirements  traceability  and  verification  matrices.  In  its  matrix,  the  System 
Specification  shows  internal  links  among  its  paragraphs.  In  the  Space  and 
Control  Segments’  specifications,  their  matrices  define  links  between  their 
respective  requirements  and  requirements  in  the  System  Specification.  This  type 
of  traceability  format  is  full  of  errors,  cumbersome,  and  lacks  depth  beyond  one 
level.  A  requirements-centric  approach  to  using  DOORS  would  offer  the 
opportunity  to  provide  greater  accuracy  and  depths  of  requirements  traceability  in 
the  GPS  Wing  database.  While  the  authors  of  the  GPS  III  Space  and  Control 
System  Specification  wrote  that  specification  to  address  the  CDD’s  requirements, 
not  all  requirements  are  linked  correctly  or  unambiguously  to  parent 
requirements: 

•  some  system  specification  requirements  trace  to  ODD  statements 
that  are  not  requirements  statements 
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•  some  system  specification  requirements  trace  to  unrelated  CDD 
requirements  statements 

•  some  system  specification  requirements  trace  to  nothing  in  the 
CDD 

(Campbell,  J.,  personal  communication,  July  25,  2006) 

These  kinds  of  situations  lead  to  difficulties  in  verifying 
requirements.  By  providing  clear  visibility  into  the  relationships  in  a  requirements 
hierarchy,  a  requirements-centric  approach  to  requirements  engineering  would 
help  the  GPS  Wing  prevent  such  traceability  and  completeness  problems  from 
occurring.  In  the  requirements-centric  approach,  child  requirements  derive 
directly  from  parent  requirements,  thereby  eliminating  the  possibility  that  a  lower- 
level  document  has  parentless  requirements  (orphans).  This  approach  would 
provide  better  visibility  into  whether  a  parent  requirement  has  all  of  the  child 
requirements  that  are  needed  to  support  eventual  satisfaction  of  the  parent 
requirement.  The  linkage  of  requirements  in  the  DOORS  project  folders  shared 
by  the  GPS  Wing  and  the  appropriate  vendor  share  would  support  requirements 
traceability  without  the  need  to  corroborate  the  requirements  statements  of 
multiple  specifications. 

c.  Testing 

A  hierarchical  structure  of  linked  requirements  implemented  with  a 
tool  like  DOORS  can  simplify  verification  planning  and  speed  requirements 
verification  itself.  Test  failures  would  be  easier  to  track  by  using  requirements 
attributes  that  address  test  status.  These  attributes  could  implement 
enumeration  types  such  as  not  tested,  pass,  or  fail.  The  default  attribute  could 
be  not  tested  until  the  systems  engineer  conducts  a  sanctioned  verification  test. 
Sanctioning  authority  would  depend  on  the  level  of  requirement  and  stage  of 
testing.  For  example,  a  system-level  test  would  require  GPS  Wing  authority  to 
modify  a  requirement’s  attribute.  As  another  example,  a  vendor  would  have 
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jurisdiction  over  subsystem  component-level  tests  for  which  these  kinds  of  lower- 
level  requirements  would  exist  initially  within  projects  created  in  the  vendor’s 
DOORS  project  folder,  and  then  be  transferred  to  the  GPS  Wing  for  inclusion 
within  its  corresponding  DOORS  project  folder. 

C.  REQUIREMENTS  CONTROL 

Even  if  the  GPS  program  adopts  a  requirements-centric  approach  for  its 
requirements  engineering  activities,  the  benefits  of  this  approach  would  be 
limited  to  some  extent  by  the  amount  of  control  the  GPS  Wing  exercises  over 
requirements.  Vendors  exercise  control  over  Segment  specifications  that,  in 
some  cases,  have  an  effect  on  the  work  of  other  vendors  that  support  other  parts 
of  the  GPS  program.  Government  control  over  the  System-level  and  Segment- 
level  specifications  would  help  the  GPS  Wing  in  its  role  as  the  prime  integrator  of 
GPS  subsystems.  Ultimately,  the  GPS  Wing  is  responsible  for  successful 
integration,  and  must  demonstrate  this  success  to  its  customers.  Vendors  should 
expect  to  support,  but  not  lead  the  integration  effort  of  the  subsystems  they 
deliver. 

To  ensure  requirements  discipline  and  facilitate  systems  integration,  the 
GPS  Wing  should  retain  control  over  System-level  and  Segment-level 
requirements  for  the  GPS  III  Space  Segment  and  Control  Segment  contracts. 
The  program  learned  through  experience  already  that  it  is  risky  to  allow  a  prime 
subsystem  vendor  to  be  the  major  subsystems  integrator  of  deliverables  for 
different  Segments.  Vendors  seeking  to  pass  verification  events  have  two 
choices  when  their  products  fail  to  pass  a  test  in  the  specified  environment — they 
can  either  redesign  a  product  so  that  it  will  pass,  or  the  vendor  can  relax  the 
requirements  until  a  product  passes  its  test.  The  latter  option  is  often  less 
desirable  to  the  government  because  the  government  is  stuck  with  the 
consequences.  Vendors’  customers  (like  the  GPS  Wing)  will  most  likely  prefer  a 
choice  over  whether  there  will  be  a  product  redesign — which  would  add  schedule 
and  cost  to  a  program — or  whether  it  would  prefer  to  relax  the  vendor’s 
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requirements.  Without  understanding  the  impacts,  the  government  is  not  likely  to 
accept  the  relaxation  of  a  requirement. 

D.  THE  DRAFT  REQUIREMENTS  OPERATING  INSTRUCTION  (01)  AND 

THE  DOORS  01— EXPECTED  IMPACTS  AND  RECOMMENDATIONS 

The  GPS  Wing’s  direction  regarding  requirements  engineering  activities 
will  be  captured  by  two  operating  instructions — the  Requirements  01  and  the 
DOORS  01.  The  Systems  Engineering  Division  would  like  both  approved  before 
the  end  of  2006.  The  Requirements  01  will  offer  important  advice  about  defining 
requirements  effectively,  which  should  make  it  an  effective  companion  document 
for  the  DOORS  01.  The  DOORS  01  will  discuss  links  to  support  traceability,  but 
the  document-centric  focus  on  the  ODD  and  specifications  make  linking 
requirements  more  difficult.  The  DOORS  01  would  have  a  greater  positive 
impact  on  the  GPS  program  if  it  directs  a  requirement-centric  approach  to 
requirements  engineering  and  directed  the  use  of  its  listed  attributes. 

The  Requirements  Ol’s  checklist  for  defining  requirements  will  help 
program  personnel  to  improve  the  statement  of  requirements.  Shown  already  in 
Chapter  3,  the  checklist  is  as  follows: 

•  Is  it  clear? 

•  Is  it  as  short  as  it  can  be? 

•  Does  it  apply  to  a  defined  type  of  user? 

•  Does  it  have  a  reasonable  priority? 

•  Is  it  verifiable? 

•  Is  it  a  single  requirement? 

•  Is  its  source  shown? 

•  Does  it  have  a  unique  identifier? 
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•  Is  it  genuinely  a  user  requirement,  not  a  design  constraint? 

(Chief  Engineer  GPS  Wing,  2006b  draft) 

This  checklist  of  questions  will  help  personnel  make  a  determination  about 
whether  to  restate  a  requirement  or  to  eliminate  it.  Restating  a  requirement  may 
actually  require  that  the  requirement  statement  be  longer  or  be  broken  into 
distinct  parts  in  order  to  capture  its  entire  intent  or  satisfy  multiple  stakeholders 
throughout  the  GPS  program.  The  goal  should  be  to  capture  all  the  information 
that  is  necessary  to  design  the  system,  include  nothing  more  than  what  is 
necessary,  and  document  this  information  in  a  way  that  prevents  ambiguity. 

Mandating  the  recommended  attributes  listed  in  the  draft  DOORS  01 
would  help  ensure  consistent  requirements  documentation  practices  across  the 
GPS  program.  Doing  so  would  also  help  to  satisfy  the  Draft  Requirements  01 
checklist  by  ensuring  answers  to  some  of  the  checklist  questions,  such  as  those 
that  address  verification  and  priority.  Of  all  the  GPS  subsystem  development 
programs,  the  User  Segment  Group’s  Advanced  Digital  Antenna  Panel  (ADAP) 
DOORS  project  folder  demonstrates  the  best  example  of  using  attributes  among 
the  GPS  Segment’s  programs.  Most  other  subsystem  development  programs 
use  no  attributes  other  than  the  attributes  assigned  automatically  by  DOORS. 
The  reason  why  the  nonuse  of  attributes  is  likely  to  continue  stems  from  the 
document-centric  approach  to  requirements  management  that  allows  program 
personnel  to  access  requirements  documents  without  accessing  DOORS.  Much 
of  the  information  that  would  exist  as  requirements  attributes  does  not  exist  in 
these  requirements  documents.  Consequently,  decision  makers  will  not  have 
convenient  access  to  this  information. 

E.  THE  USE  OF  THE  WORD  SHALL  IN  SPECIFICATIONS,  INTERFACE 

CONTROL  DOCUMENTS  AND  INTERFACE  SPECIFICATIONS 

The  statement  of  requirements  in  ICDs  and  ISs  underscores  a  problem 
the  GPS  Wing  faces  with  its  vendors.  ICDs  should  merely  describe  external  and 

internal  interfaces  rather  than  also  specify  requirements.  However,  vendors 
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claim  that  without  shall  statements,  certain  activities  are  out  of  the  scope  of  their 
contract.  The  use  of  ‘shall’  statements  in  ICDs  and  ISs  solves  the  government’s 
problem  of  getting  vendors  to  verify  that  the  systems  they  deliver  will  interface 
properly  with  the  other  GPS  subsystems.  However,  because  the  intent  of 
interface  documents  is  to  describe  rather  than  require,  the  GPS  Wing  will  need  to 
ensure  that  future  contracts  include  requirements  for  verification  of  not  only  the 
vendor’s  deliverables,  but  also  the  proper  interface  of  these  deliverables  with 
other  GPS  subsystems.  In  the  absence  of  a  shift  away  from  specification 
documents,  compliance  documents  such  as  system  or  segment  specifications 
would  be  a  more  appropriate  place  to  levy  verification  requirements  for 
interfaces.  In  a  requirements-centric  model,  verification  requirements  would 
need  to  exist  at  the  segment  or  system  level  also. 

Vendors  have  clear  and  particular  definitions  for  the  words  like  shall,  must, 
and  will.  If  the  vendors  agree  to  include  ICDs,  ISs,  and  specifications  as 
compliance  documents  on  their  contracts,  then  these  documents  shall  include 
the  word  shall  to  help  designate  vendors’  requirements.  The  remaining  risk  with 
respect  to  the  use  of  this  word  is  that  the  government  has  not  issued  a  current 
and  precise  definition  of  shall  or  any  other  such  words  to  be  agreed  upon  by  all 
vendors.  (The  government  rescinded  MIL-STD-961,  which  defined  shall,  will, 
and  should.)  Instead,  it  is  the  vendor  who  defines  the  meaning  of  these  as  well 
as  other  terms,  such  as  must,  that  may  not  have  military-wide  or  even  GPS 
program-wide  accepted  meanings.  For  a  program  in  which  there  are  different 
vendors  responsible  for  developing  and  producing  different  subsystems,  any 
inconsistencies  in  vendors’  use  and  interpretations  of  these  kinds  of  terms 
increase  the  risk  of  incompatibilities  due  to  unsatisfied  requirements.  In  addition 
to  technical  issues,  differences  in  interpretation  over  whether  a  statement  is  a 
requirement  or  not  can  also  lead  to  contractual  difficulties  that  delay  the  pursuit  of 
a  necessary  technical  solution. 

The  government  should  redefine  the  definition  of  shall  and  any  other 
words  it  intends  for  use  in  defining  the  contractual  obligations  of  the  government 
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and  its  vendors.  After  doing  so,  the  government  should  also  ensure  proper  and 
consistent  use  of  these  terms  in  its  capabilities  documents  and  specifications. 
The  GPS  program  has  a  Block  III  CDD  for  the  Space  and  Control  Segments  that 
uses  statements  with  words  other  than  shall  that  appear  to  be  requirements 
statements.  For  example,  the  word  should  appears  throughout  the  CDD — 
including  several  instances  in  Section  6:  System  Capabilities  Required  for  the 
Current  Increment.  MIL-STD-961  stated  that  the  word  should  relates  to  a  goal. 
However,  there  is  no  current  government-approved  definition  for  should  that 
applies  to  military  acquisition  programs,  and  this  word  is  not  defined  in  the  CDD 
either. 

F.  CHAPTER  SUMMARY 

This  chapter  offers  suggestions  for  improving  the  GPS  program’s 
requirements  engineering  and  system  integration  effectiveness  by  standardizing 
on  technology  already  available  to  the  program.  Currently,  the  GPS  program  is 
not  practicing  an  effective  way  to  develop,  manage,  verify  requirements;  or 
include  consistent  practices  across  subsystem  acquisition  programs.  Although 
the  GPS  program  and  its  vendors  have  a  tool  capable  of  supporting  a 
requirements-centric  approach,  they  are  not  using  the  DOORS  tool  to  do  so. 
However,  the  program  has  taken  steps  in  2006  to  improve  its  requirements 
engineering  activities  by  writing  operating  instructions  that  provide  direction  to 
program  personnel;  but  there  are  still  opportunities  to  improve  the  draft  DOORS 
Ol.  The  draft  Requirements  OI  will  eventually  close  a  gap  in  program  direction 
regarding  requirements  engineering.  While  this  chapter  recommends 
abandoning  a  document-centric  approach  in  favor  of  a  requirements-centric 
approach,  current  realities  that  face  the  program  will  likely  divert  decision¬ 
makers’  collective  attention  towards  overcoming  higher  priority  financial, 
schedule,  and  technical  challenges. 
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V.  CONCLUSIONS 


A.  INTRODUCTION 

This  research  proposes  ways  to  improve  the  requirements  engineering 
work  at  the  Air  Force’s  GPS  Wing,  the  acquisition  program  office  for  this  civil- 
military  system.  The  ultimate  benefit  is  faster  and  better-informed  decisions 
made  by  GPS  program  leaders  who  must  balance  the  needs  of  multiple 
stakeholders.  These  stakeholders  rely  on  this  system  for  positioning,  velocity, 
and  timing  services.  While  decisions  ultimately  depend  on  human  interaction 
and  persuasion,  organizing  the  requirements  information  effectively  can  lead  to  a 
better  decision-making  process.  When  relevant  information  is  available  in  a 
useful  standard  format,  people  make  more  informed,  rational  and  confident 
decisions. 

For  the  GPS  Wing  to  be  effective,  all  three  segments — Space,  Control, 
and  User — must  work  together.  As  a  result,  the  GPS  Wing  must  ensure  proper 
allocation  of  requirements  across  these  segments  and  integrate  the  subsystem 
acquisition  program  deliverables  from  these  segments.  The  Wing  should 
consider  its  investment  of  time,  training,  and  funds  carefully  when  evaluating 
requirements  methodologies  that  support  integration  efforts.  The  GPS  Wing  and 
its  vendors  use  the  same  DOORS  database  tool  and  have  experimented  with 
exchanging  DOORS  files.  By  changing  its  model  and  processes  to  take 
advantage  of  the  features  offered  by  DOORS,  the  Wing  can  achieve  more 
efficient  integration. 

B.  CURRENT  PROGRAM  REALITIES 

While  the  program  managers  and  engineers  of  GPS  Wing  recognize  the 
need  to  improve  requirements  engineering  practices,  current  realities  facing  the 
program  pose  challenges  to  doing  so.  The  program  has  seen  different  rates  of 
progress  on  all  three  Segment  modernization  efforts  because  of  technical, 
schedule,  and  cost  constraints.  While  the  program  must  deliver  on  its  technical 
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obligations  and  overcome  its  schedule  delays,  the  current  resource-constrained 
defense  acquisition  environment  adds  another  obstacle  to  meeting  the  emerging 
needs  of  civil  and  military  users.  Customers  like  HQ  USAF  have  even  asked  the 
GPS  Wing  to  compress  future  capability  deliveries  while  the  GPS  Wing  faces 
repeated  reductions  in  its  technical  staff.  The  GPS  and  other  development 
programs  operate  under  a  schedule-driven  environment  in  which  the  Control 
Segment  Group  is  attempting  to  meet  a  December  2006  target  for  releasing  its 
already-delayed  Request  for  Proposal  (RFP)  for  the  Block  III  Control  Segment 
contract.  By  having  a  schedule-driven  RFP  rather  than  an  event-driven  one,  the 
GPS  Wing  faces  an  increased  risk  that  it  will  miss  requirements. 

The  GPS  Wing  has  recognized  that  it  should  improve  its  requirements 
engineering  practices  by  drafting  the  Requirements  and  DOORS  Operating 
Instructions  (Ols).  These  are  unprecedented  documents  that  will  standardize 
requirements  engineering  across  the  Wing  for  the  first  time.  The  completed  draft 
DOORS  01  has  room  for  improvement,  and  the  enforcement  of  this  01  for  older 
programs  may  have  costs  that  do  not  outweigh  the  benefits.  Long  term  benefits 
are  possible  when  using  a  requirements-centric  approach  that  emphasizes 
reusing  existing  requirements  objects.  Creating  new  requirements  objects  to 
replace  legacy  objects  would  also  make  requirements  development  easier. 
When  completed  and  approved,  the  Requirements  01  should  provide  the 
guidance  that  is  necessary  to  promote  a  consistently  high  level  of  quality  for 
requirements  across  Segment  development  programs. 


C.  KEY  POINTS  AND  RECOMMENDATIONS 

This  research  paper  discusses  all  three  facets  to  a  requirements 
engineering  methodology:  models,  tools,  and  techniques. 

First,  a  requirements-centric  approach  or  model  would  benefit  the  GPS 
Wing’s  requirements  development,  management  and  verification  efforts. 
However,  this  kind  of  approach  would  require  changes  to  the  other  two  facets  of 
the  methodology:  tools  and  techniques. 

90 


Second,  the  Wing  can  strengthen  its  requirements  engineering  efforts  by 
taking  advantage  of  underutilized  DOORS  features  such  as  attribute  definition 
and  linking  to  support  requirements  traceability. 

Third,  the  GPS  Wing  has  begun  to  define  techniques  for  the  first  time  in 
the  draft  Requirements  and  DOORS  Operating  Instructions.  Implementation  and 
enforcement  of  these  Ols  will  help  improve  the  requirements  quality. 

Even  with  a  shift  in  its  requirements  engineering  methodology,  there  are 
other  ways  that  the  GPS  Wing  could  improve  the  way  it  handles  its  requirements. 
The  GPS  Wing  would  also  serve  its  customers  better  by  insisting  to  its  vendors 
that  the  GPS  Wing  control  the  top-level  requirements  baselines  and  interface 
definitions. 

For  example:  The  GPS  Wing  learned  from  its  experiences  with  the  Block 
HR  Space  contract  and  the  Block  IIF  Space  and  Control  contract  that  government 
loss  of  control  over  the  technical  baselines  for  subsystem  deliverables  causes 
contractual  and  integration  difficulties.  These  difficulties  increase  costs  and 
delay  schedules. 

As  the  system  integrator,  the  GPS  Wing  could  reduce  integration  costs 
and  ensure  that  subsystem  deliverables  work  together  properly.  When  vendors 
seek  a  change  to  requirements  or  interfaces  that  the  government  controls,  the 
government  can  then  lead  the  decision-making  process  to  decide  how  it  would 
prefer  to  handle  the  proposed  change.  The  current  situation  is  untenable  where 
the  GPS  Wing  finds  itself  forced  to  help  one  vendor  adapt  to  changes  made  by 
another  vendor. 

In  its  contracts  with  vendors,  the  GPS  Wing  should  also  provide  a  single 
set  of  definitions  for  key  terms  that  help  to  define  the  roles  and  obligations  of  the 
GPS  Wing,  other  government  entities,  and  all  vendors  who  develop  and  produce 
GPS  subsystem  deliverables.  Disputes  and  questions  over  contractual 
agreements  cost  the  GPS  Wing  precious  funds  and  development  time.  If  the 
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GPS  Wing  defined  these  key  terms,  vendors  would  not  need  to  specify 
definitions  for  these  terms  that  may  vary  from  one  vendor  to  another. 

Over  the  last  decade,  the  GPS  Wing  has  learned  from  its  contractual 
experiences  that  it  must  do  a  better  job  of  specifying  clear  and  complete 
requirements  to  vendors  in  order  to  ensure  that  subsystem  deliverables  are 
operationally  suitable. 

One  example  of  inadequate  requirements  specification  involves  the  lack  of 
vendor  support  for  the  transition  to  operations  of  the  Block  IIP  Control  Segment 
software  and  hardware  deliverables.  Another  example  comes  from  the  vendor 
belief  that  ‘shall’  statements  in  ICDs  and  ISs  are  necessary  to  ensure  that 
vendors  verify  the  performance  of  interfaces  between  their  deliverables  and  other 
GPS  subsystems. 

The  government  needs  to  ensure  that  it  specifies  a  complete  set  of 
requirements  that  cover  all  system  acquisition  needs.  Unfortunately,  bad 
program  experiences  are  the  motivation  behind  the  draft  Requirements  01  to 
improve  and  standardize  GPS  Wing  requirements  engineering  practices. 


D.  AREAS  FOR  CONDUCTING  FURTHER  RESEARCH 

Even  if  the  GPS  Wing  were  already  following  the  recommendations  of  this 
research  paper,  there  would  still  be  other  areas  to  search  for  improvements  to 
the  GPS  program’s  requirements  engineering  methodology.  Rather  than  making 
the  best  use  of  available  resources  such  as  the  DOORS  tool,  research  could 
focus  on  evaluating  the  combination  of  tools  and  techniques  that  would  support 
the  GPS  programs  interests  best. 
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